Bug#908681: libsane1: pointless package rename

[Vincent Lefevre]

On 2020-10-05 15:35:23 +0200, Gianfranco Costamagna wrote:
> In this case, the symbols were private, and incorrectly exposed
> outside, so removing them is "safe" as long as nobody uses them.

I've looked at the repository, and in more details, they were
incorrectly exposed outside via the symbol table, but not via
a header file.[*] Thus I agree that there is no chance that
anyone uses them via the API.

[*] as the issue was fixed only by adding "static":

commit 62614a46609d85f03d9b73a826f8c94a3554e2b1
Author: Povilas Kanapickas 
Date:   2020-03-28 21:08:39 +0100

sanei_usb: Use internal linkage for private static variables

diff --git a/sanei/sanei_usb.c b/sanei/sanei_usb.c
index db0f452ae..291a48024 100644
--- a/sanei/sanei_usb.c
+++ b/sanei/sanei_usb.c
@@ -195,15 +195,15 @@ static sanei_usb_testing_mode testing_mode = 
sanei_usb_testing_mode_disabled;
 
 #if WITH_USB_RECORD_REPLAY
 static int testing_development_mode = 0;
-int testing_known_commands_input_failed = 0;
-unsigned testing_last_known_seq = 0;
-SANE_String testing_record_backend = NULL;
-xmlNode* testing_append_commands_node = NULL;
+static int testing_known_commands_input_failed = 0;
+static unsigned testing_last_known_seq = 0;
+static SANE_String testing_record_backend = NULL;
+static xmlNode* testing_append_commands_node = NULL;
 
 // XML file from which we read testing data
-SANE_String testing_xml_path = NULL;
-xmlDoc* testing_xml_doc = NULL;
-xmlNode* testing_xml_next_tx_node = NULL;
+static SANE_String testing_xml_path = NULL;
+static xmlDoc* testing_xml_doc = NULL;
+static xmlNode* testing_xml_next_tx_node = NULL;
 #endif // WITH_USB_RECORD_REPLAY
 
 #if defined(HAVE_LIBUSB_LEGACY) || defined(HAVE_LIBUSB)

> So, yes, the ABI changed, but the change was not reflected into
> a real issue for any Debian application, or any custom-built
> application.

Actually, though the symbol table changed, the ABI didn't.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#908681: libsane1: pointless package rename

[Gianfranco Costamagna]

Hello Joerg,

> We are not back.

to be honest, yes we are :)

> 
> Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer 
> available:
> 
> #MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29
> #MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29
> #MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29
> #MISSING: 1.0.31# testing_record_backend@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_doc@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_path@Base 1.0.29
> 
> This ABI changes are not backward-compatible. And so the change are required. 
> 

So, to explain:

If you think they are not backward-compatible, you should rename the package, 
but not provide the old SONAME
as transitional package, otherwise you are doing a mistake

In this case, the symbols were private, and incorrectly exposed outside, so 
removing them is "safe"
as long as nobody uses them.

When I sponsored the package for you, even if I forgot to write that on the RFS 
bug, I had a discussion about this
with some other DDs, and we agreeded that this wasn't worth a SONAME change, 
because the end user applications
were still ABI-safe.

So, this is why I asked you to restore the old package name, and make it 
transitional, to avoid people being forced
to upgrade to a new library SONAME without a real SONAME change.

This way, we made almost "everybody" happy, or at least improved the status quo 
for some bits.

(the real world fix was to ignore lintian, or to not start with a wrong soname, 
but this history now)

So, yes, the ABI changed, but the change was not reflected into a real issue 
for any Debian application, or any custom-built application.

I honestly think we should just move forward, and change the soname again if a 
the library changes in the future.

G.

Bug#908681: libsane1: pointless package rename

[Vincent Lefevre]

On 2020-10-04 18:26:31 +0200, Vincent Lefevre wrote:
> On 2020-10-04 17:59:33 +0200, Jörg Frings-Fürst wrote:
> > We are not back.
> > 
> > Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer 
> > available:
> > 
> > #MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29
> > #MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29
> > #MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29
> > #MISSING: 1.0.31# testing_record_backend@Base 1.0.29
> > #MISSING: 1.0.31# testing_xml_doc@Base 1.0.29
> > #MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29
> > #MISSING: 1.0.31# testing_xml_path@Base 1.0.29
> > 
> > This ABI changes are not backward-compatible. And so the change are 
> > required. 
> > 
> > Therefore I close this bug.
> 
> No, the bug is still valid: if there are backward-incompatible
> changes, the soname must be changed. But it hasn't.

So, that's now bug 971668.

Note that in 1.0.30, the package had already been renamed to libsane1.
So the soname must be bumped and the package needs to be renamed again
(following the soname bump).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#908681: libsane1: pointless package rename

[Vincent Lefevre]

On 2020-10-04 17:59:33 +0200, Jörg Frings-Fürst wrote:
> We are not back.
> 
> Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer 
> available:
> 
> #MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29
> #MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29
> #MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29
> #MISSING: 1.0.31# testing_record_backend@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_doc@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_path@Base 1.0.29
> 
> This ABI changes are not backward-compatible. And so the change are required. 
> 
> Therefore I close this bug.

No, the bug is still valid: if there are backward-incompatible
changes, the soname must be changed. But it hasn't.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#908681: libsane1: pointless package rename

[Jörg Frings-Fürst]

Hello,

Am Sonntag, den 04.10.2020, 16:44 +0200 schrieb Sebastian Ramacher:
> Control: reopen -1
> Control: found -1 1.0.31-2
> Control: fixed -1 1.0.27-3.1
> 
> On 2018-09-12 16:14:51 +0200, Julien Cristau wrote:
> > Package: libsane1
> > Severity: serious
> > 
> > Hi,
> > 
> > libsane was renamed to libsane1 for apparently no good reason.  Renames
> > for library packages should be tied to ABI breakage (and associated
> > SONAME changes).
> > 
> > Either there was ABI breakage and the SONAME should be bumped (and
> > Provides: libsane would be wrong), or there wasn't and the package name
> > change ought to be reverted.
> > 
> > I don't know which it is, and when I asked I didn't get a clear answer,
> > so I'll ask again here.
> 
> We are back to square 1. When asked again in #960046 the question was
> simply ignored and it got uploaded anyway.
> 
We are not back.

Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer available:

#MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29
#MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29
#MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29
#MISSING: 1.0.31# testing_record_backend@Base 1.0.29
#MISSING: 1.0.31# testing_xml_doc@Base 1.0.29
#MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29
#MISSING: 1.0.31# testing_xml_path@Base 1.0.29

This ABI changes are not backward-compatible. And so the change are required. 

Therefore I close this bug.



> Cheers

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



signature.asc
Description: This is a digitally signed message part

Bug#908681: libsane1: pointless package rename

[Sebastian Ramacher]

Control: reopen -1
Control: found -1 1.0.31-2
Control: fixed -1 1.0.27-3.1

On 2018-09-12 16:14:51 +0200, Julien Cristau wrote:
> Package: libsane1
> Severity: serious
> 
> Hi,
> 
> libsane was renamed to libsane1 for apparently no good reason.  Renames
> for library packages should be tied to ABI breakage (and associated
> SONAME changes).
> 
> Either there was ABI breakage and the SONAME should be bumped (and
> Provides: libsane would be wrong), or there wasn't and the package name
> change ought to be reverted.
> 
> I don't know which it is, and when I asked I didn't get a clear answer,
> so I'll ask again here.

We are back to square 1. When asked again in #960046 the question was
simply ignored and it got uploaded anyway.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#908681: libsane1: pointless package rename

[Nils Schasse]

Hi,

is this related to conflicts with the gnome package in sid?

(apt dist-upgrade)

To be removed:
  colord gnome gnome-color-manager gnome-control-center gnome-core
libsane1 libsane1:i386 sane-utils simple-scan task-gnome-desktop
Held back:
  libtiff5
Upgrade:
  libsane-common

Regards,
Nils


signature.asc
Description: This is a digitally signed message part

Bug#908681: libsane1: pointless package rename

[John Paul Adrian Glaubitz]

Hi Laurent!

On 11/6/18 2:09 AM, Laurent Bigonville wrote:
> This bug is open for more than a month without any recent reaction from the 
> maintainer, multiple people have asked for the status over the month of 
> October (including mails addressed directly to the maintainer), nothing.

That bug was forced upon the maintainer. He made his decision, others disagreed
and used their positions to push their opinion on him. However, so far I have 
not
seen any reference to the Debian Policy which grants such a particular right.

> This is/was blocking the migration of some packages to testing (at least one 
> from GNOME, that's why I start caring).

That was not Joerg's fault. He maintained his package with a lot of diligence
while no one else was interested in maintaining this package.

> I felt reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908681#99 
> that some kind of consensus was reached, that was maybe incorrect.

There was no consensus from the maintainer. There were people pushing on Joerg,
you jumping on the bandwagon and forcing the change on him. Again, no 
justification
with reference to corresponding parts of the Debian Policy.

> Not much more to say here.

So you think it's acceptable to override maintainer decisions without the CTTE
which is supposed to be used in this context? Would you be okay for this to
be done with your packages, too?

> Laurent Bigonville who just spent his last care replying to this mail.

Not sure I understand what you mean?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#908681: libsane1: pointless package rename

[Laurent Bigonville]

Le 5/11/18 à 23:54, John Paul Adrian Glaubitz a écrit :

Hello Lauren!

Hello,

Is there any reason why you are hijacking the package here and overriding
a maintainer's decision without contacting the Debian CTTE?


This bug is open for more than a month without any recent reaction from 
the maintainer, multiple people have asked for the status over the month 
of October (including mails addressed directly to the maintainer), nothing.


This is/was blocking the migration of some packages to testing (at least 
one from GNOME, that's why I start caring).


I felt reading 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908681#99 that some 
kind of consensus was reached, that was maybe incorrect.


Not much more to say here.

Laurent Bigonville who just spent his last care replying to this mail.

Bug#908681: libsane1: pointless package rename

[John Paul Adrian Glaubitz]

On 11/6/18 12:04 AM, Paul Tagliamonte wrote:
> Was this a hijack or NMU? I saw a NMU to DELAYED with a log
> in the bug announcing it. I may have missed something

I'm the sponsor, I was not put in the loop over this decision
and Joerg may not have been available the past three days.

Joerg Frings-Fuerst as the maintainer made a decision. That decision
was not accepted by Julien who opened an RC bug. Joerg disagreed with
that but felt he didn't have any voice against a member of the stable
release team.

Then Laurent came around, not knowing the discussion and uploaded a
an NMU just informing the maintainer not me with just a three days
heads-up and now we have another person overriding a maintainer's
decision.

I'm not sure why that upload happened. 

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#908681: libsane1: pointless package rename

[Paul Tagliamonte]

Was this a hijack or NMU? I saw a NMU to DELAYED with a log in the bug
announcing it. I may have missed something

paultag

Bug#908681: libsane1: pointless package rename

[John Paul Adrian Glaubitz]

Hello Lauren!

Is there any reason why you are hijacking the package here and overriding
a maintainer's decision without contacting the Debian CTTE?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#908681: libsane1: pointless package rename

[Philip Rinn]

Hi Jörg,

it seems there is an accepted solution for this bug since almost two weeks:

- rename libsane1 back to libsane
- add a "Provides: libsane1" to libsane

see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908681#51

Why isn't that route followed?

Thanks,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#908681: libsane1: pointless package rename

[Philip Rinn]

On 14.10.18 at 14:35 Jeremy Bicha wrote:
> Control: severity -1 serious
> 
> On Sat, 13 Oct 2018 at 19:59:38 Philip Rinn  wrote:
>> Control: -1 severity normal
>>
>> Hi,
>>
>> I lower the severity of this bug as I couldn't find a severe violation of the
>> Debian policy - please point me to it if I missed something.
>>
>> Best,
>> Philip
> 
> This bug was filed by Julien Cristau. I believe the bug was filed in
> his role as Stable Release Manager. Therefore, serious is the
> appropriate bug severity.

True, I missed that.

Bug#908681: libsane1: pointless package rename

[Jeremy Bicha]

Control: severity -1 serious

On Sat, 13 Oct 2018 at 19:59:38 Philip Rinn  wrote:
> Control: -1 severity normal
>
> Hi,
>
> I lower the severity of this bug as I couldn't find a severe violation of the
> Debian policy - please point me to it if I missed something.
>
> Best,
> Philip

This bug was filed by Julien Cristau. I believe the bug was filed in
his role as Stable Release Manager. Therefore, serious is the
appropriate bug severity.

https://www.debian.org/intro/organization#distribution
https://www.debian.org/Bugs/Developer#severities

Thanks,
Jeremy Bicha

Bug#908681: libsane1: pointless package rename

[Philip Rinn]

Control: -1 severity normal

Hi,

I lower the severity of this bug as I couldn't find a severe violation of the
Debian policy - please point me to it if I missed something.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#908681: libsane1: pointless package rename

[Jeremy Bicha]

On Wed, Sep 26, 2018 at 12:06 AM Jeremy Bicha  wrote:
> Some libraries have way too many public symbols and many of the
> symbols aren't considered part of the API so dropping or changing them
> isn't a serious problem.

Yeah, the API is far shorter than the 7000 symbols according to its
most recent documentation. I don't think the dropped symbols will
cause problems for any third-party drivers.
http://sane-project.org/html/

Julien, would you be at all interested in keeping the libsane name but
with a Provides: libsane1 ?

Thanks,
Jeremy Bicha

Bug#908681: libsane1: pointless package rename

[Jeremy Bicha]

The question here is difficult. My initial thinking was that the
rename was unnecessary. Eventually, I added the Provides as a
compromise.

The issue is that there are third-party scanner driver .deb packages
that won't be quickly re-compiled against the new sane-backends. I do
see that there are symbols dropped in the new version, but it's
difficult for me to tell whether those symbols are used by third-party
drivers.

Some libraries have way too many public symbols and many of the
symbols aren't considered part of the API so dropping or changing them
isn't a serious problem. libsane1.symbols.amd64 is over 7300 lines
long so I guess this could be the case here. A typical way we can
verify whether the dropped symbols are worth worrying about is to use
https://codesearch.debian.net/ but that doesn't help here since most
of this library's users are outside Debian.

One more point: Ubuntu 18.04 LTS shipped with the bumped soname and
the Provides. That means that any driver packages built against Ubuntu
18.04 will depend on libsane1 instead of the old libsane name. In that
case, maybe the current package with the bumped soname and Provides is
acceptable for Buster too.

Thanks,
Jeremy Bicha

Bug#908681: libsane1: pointless package rename

[Julien Cristau]

On 09/16/2018 10:54 PM, Jörg Frings-Fürst wrote:
> Hello Julien,
> 
> 
> Am Mittwoch, den 12.09.2018, 16:14 +0200 schrieb Julien Cristau:
>> Package: libsane1
>> Severity: serious
> 
>> Hi,
> 
>> libsane was renamed to libsane1 for apparently no good
>> reason.  Renames
>> for library packages should be tied to ABI breakage (and associated
>> SONAME changes).
> 
> 
> According to Debian Policy 8.6.2, renaming of the SONAME and the
> library package name is possible for non-backwards compatible ABI
> changes.
> 
> The SONAME is for a longer time 1: 
> 
> $ objdump -p ./libsane.so.1.0.27 | grep SONAME
>   SONAME   libsane.so.1
> 
> $ objdump -p ./libsane.so.1.0.25 | grep SONAME
>   SONAME   libsane.so.1
> 
> Between libsane.so.1.0.25 and libsane.so.1.0.27 are some symbols
> removed. Therefore the change the library from libsane to libsane1
> are possible.

But the SONAME didn't change here.

>> Either there was ABI breakage and the SONAME should be bumped (and
>> Provides: libsane would be wrong), or there wasn't and the package
>> name
>> change ought to be reverted.
> 
> 
> The changes 
> 
> -Breaks: libsane (<<1.0.27-1)
> -Replaces: libsane (<<1.0.27-1)
> -Pre-Depends: ${misc:Pre-Depends}
> +Conflicts: libsane (<< 1.0.27-1~)
> +Replaces: libsane (<< 1.0.27-1~)
> +Provides: libsane (= ${binary:Version})
> 
> were requested by Jeremy Bicha and taken over after consultation with
> my mentor.
> 
You can't have it both ways.  Either 1.0.27 is not backwards-compatible
with the old libsane, and so you can't Provide it (Provides is a
statement of compatibility).  Or they're compatible, and the package
name shouldn't have changed.  It's one or the other, it can't be
backwards-incompatible and compatible at the same time.  I didn't look
at it, and would prefer not to have to, so I don't know which it is, but
your statements contradict themselves so they're not really giving
information one way or the other.

Cheers,
Julien

Bug#908681: libsane1: pointless package rename

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Julien,


Am Mittwoch, den 12.09.2018, 16:14 +0200 schrieb Julien Cristau:
> Package: libsane1
> Severity: serious
> 
> Hi,
> 
> libsane was renamed to libsane1 for apparently no good
> reason.  Renames
> for library packages should be tied to ABI breakage (and associated
> SONAME changes).
> 

According to Debian Policy 8.6.2, renaming of the SONAME and the
library package name is possible for non-backwards compatible ABI
changes.

The SONAME is for a longer time 1: 

$ objdump -p ./libsane.so.1.0.27 | grep SONAME
  SONAME   libsane.so.1

$ objdump -p ./libsane.so.1.0.25 | grep SONAME
  SONAME   libsane.so.1

Between libsane.so.1.0.25 and libsane.so.1.0.27 are some symbols
removed. Therefore the change the library from libsane to libsane1
are possible.

> Either there was ABI breakage and the SONAME should be bumped (and
> Provides: libsane would be wrong), or there wasn't and the package
> name
> change ought to be reverted.
> 

The changes 

- -Breaks: libsane (<<1.0.27-1)
- -Replaces: libsane (<<1.0.27-1)
- -Pre-Depends: ${misc:Pre-Depends}
+Conflicts: libsane (<< 1.0.27-1~)
+Replaces: libsane (<< 1.0.27-1~)
+Provides: libsane (= ${binary:Version})

were requested by Jeremy Bicha and taken over after consultation with
my mentor.

> I don't know which it is, and when I asked I didn't get a clear
> answer,
> so I'll ask again here.
> 
> Cheers,
> Julien


CU
Jörg
- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluewxkACgkQCfifPIyh
0l2hrxAAukOnYhcZIW8DUY3k/3f3l+7OcWrZs2fS3nvg3NvxGAVIATksbFXswCAm
o0G+LFRUOrZWwgnIMxTL85acnszIZ3u8RglmWbKjlmK5wJ/d8xeefU4ZizrWHVJY
g7HBI7tgkXk2H2eVmVIMT3B+hiVSBSShpTi1x3Mhq0IYs/1j8dlDNQ7tvU3iPkoU
75UoZQC55JS15CZLE6LAqESqgP9FPtSlAvHdLUqF9hS5jITdUpLr+Fbxg0fYszQq
rw+8+yw6BYumkfGhru4wC9BisxpfL8wjsmNQkeat2H02+X/93NaZvl6TNApe6Any
gCPVRHlAyyEUbfgfONLsGkP2aKV07izc+RSg9jwW5qDat+tM1qjT4MfXxWNnGz22
dKSjcOhudut8807R6M2e/6yJpOPAumXMOLjY7UPmfmgxKsbFsDgCH2+IWL0xFnkG
yGj6zHrjCOzO2zIBmtcxG6CdeYTCp+k95QKKTTQEPG9x9POy9wBjN+HC95r7L7Bh
Ne9yueBoKgSYxXhfuENXvwHJvKfVPAcH6jKlhYUegS0XGTkKliGhCdC4K0clxMA7
Vfph57wuU535j3rZCRI/l1s8vvUxeh4THT597xNMS3U2jz2ksLM9h+PEJy+Lx9hB
yJOdWv0dTvG7C7acflepG1yL3FuDMKauYPVvhz9BADKGcahpCBM=
=C/cV
-END PGP SIGNATURE-

Bug#908681: libsane1: pointless package rename

[Julien Cristau]

Package: libsane1
Severity: serious

Hi,

libsane was renamed to libsane1 for apparently no good reason.  Renames
for library packages should be tied to ABI breakage (and associated
SONAME changes).

Either there was ABI breakage and the SONAME should be bumped (and
Provides: libsane would be wrong), or there wasn't and the package name
change ought to be reverted.

I don't know which it is, and when I asked I didn't get a clear answer,
so I'll ask again here.

Cheers,
Julien