Discussion:
Fix PPA build
(too old to reply)
James Duvall
2017-05-08 20:22:35 UTC
Permalink
Raw Message
Rolf,
Thanks for getting your ppa back up and running.  However, I am not able to install the libsane package using apt, even when I try to force the version.  I believe that your new version numbering with ~ is causing the problem.

ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver libsane-common=$ver sane-utils=$ver
Apt complains that

The following packages have unmet dependencies:
 libsane : Breaks: libsane-common (< 1.0.26)
           Breaks: libsane-common:i386 (< 1.0.26)
E: Unable to correct problems, you have held broken packages.

I think the issue is that version 1.0.26~ppa20170508-yakkety0 compares less than 1.0.26 due to special rules for handling ~ in version numbers.  The following shows this:
dpkg --compare-versions 1.0.26~ppa20170508-yakkety0 lt 1.0.26 && echo true
true
I created a local repository and re-packaged as version 1.0.26+ppa20170508-yakkety0 and was able to install with no problems, so maybe change the ~ for + or some other separator?  I am not experienced with debian package management, so please disregard if I am missing something.
James
Rolf Bensch
2017-05-09 18:35:56 UTC
Permalink
Raw Message
Hi James,
Rolf,
Thanks for getting your ppa back up and running. However, I am not able
to install the libsane package using apt, even when I try to force the
version. I believe that your new version numbering with ~ is causing
the problem.
ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver
libsane-common=$versane-utils=$ver
I used synaptic for Trusty and it's working.

You can use an alternative more complex procedure to get the updates
from my ppa:

(1) search for installed SANE packages:
$ dpkg -l *sane*

(2) purge all SANE packages with the version '1.0.26[-+]ppa{date}
*without* removing dependent packages:
$ sudo dpkg --force-all -P libsane libsane-common sane-utils [other
installed packages]

(3) reinstall SANE:
$ apt-get -f install

(4) reinstall all other removed packages, e.g.:
$ sudo apt-get install libsane-dev
Apt complains that
libsane : Breaks: libsane-common (< 1.0.26)
Breaks: libsane-common:i386 (< 1.0.26)
E: Unable to correct problems, you have held broken packages.
I think the issue is that version 1.0.26~ppa20170508-yakkety0 compares
less than 1.0.26 due to special rules for handling ~ in version
dpkg --compare-versions 1.0.26~ppa20170508-yakkety0 lt 1.0.26 && echo true
true
This is correct. SANE 1.0.26 isn't released yet.
Inspired from your comment I renamed the version in my ppa to
'1.0.26~pre{date}'. This makes it more transparent that this is a
pre-release.
I created a local repository and re-packaged as version
1.0.26+ppa20170508-yakkety0 and was able to install with no problems, so
maybe change the ~ for + or some other separator? I am not experienced
with debian package management, so please disregard if I am missing
something.
Then you'll get the next update after we started the development of SANE
version 1.0.27, then AKA version 1.0.27~pre{date} from my ppa repository

Many thanks for your report.

Hope this helps.

Cheers,
Rolf
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-11 11:36:08 UTC
Permalink
Raw Message
Hi all,

This is something that I've been wondering about for a while and with
the release coming up I thought I'd vent my thoughts/preferences on the
version numbering of sane-backends (and sane-frontends if we should ever
get around to releasing a new version of that).
Post by Rolf Bensch
Hi James,
Rolf,
Thanks for getting your ppa back up and running. However, I am not able
to install the libsane package using apt, even when I try to force the
version. I believe that your new version numbering with ~ is causing
the problem.
ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver
libsane-common=$versane-utils=$ver
On Debian-based distributions:

1.0.26~this < 1.0.26 < 1.0.26+that

I don't recall the details for RPM-based distributions re ~ (note that
Fedora[1] says it should not be used), but the + works the same, so:

1.0.26 < 1.0.26+that

[1] https://fedoraproject.org/wiki/Packaging:Versioning

The problem with the way we currently do the versioning of sane-backends
is that we bump the version to what we *think* will be the next version.
This would work for Debian-based distribution packages if they use a ~
suffix to our version. For RPM-based distributions I don't know what
works. It also causes confusing bug reports and mails to the list where
people talk about using an upcoming release.

To fix that, can we agree to a version number for HEAD on master that
refers to the last *released* version? Something like this

1.0.26+git

for anything *after* the 1.0.26 release. This should work for all folks
rolling binary packages and indicates very clearly that it's 1.0.26 plus
a bunch of edits.

Actually, we may also want to look into using the output of

git describe

When I run this on my current checkout of master, I get

RELEASE_1_0_25-552-ge6711c3

This is <tag>-<number-of-commits-since-tag>-g<commit-ish>, so this
should work fine as long as people are using master. The number of
commits since the tag will sort later commits in the right order.

# We haven't used branches much so far, so this would be a reasonably
# safe assumption. Anyway, if you're using any other branch, I would
# assume you know what you're doing ;-)

If we also switch tags to use the version number as is, that would
become

1.0.25-552-ge6711c3

# Debian-based distributions may need to replace the - with something
# else. Using `sed 's/-/+/g'` or something similar should work.

Summarizing, let's use

<last-*released*-version>+git

from the 1.0.26 release onwards and look into using the output from `git
describe` to get an even better idea of what people are really running
when compiling from git.

How's that sound?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
m. allan noah
2017-05-12 23:18:09 UTC
Permalink
Raw Message
this sounds like a reasonable plan to me, though I wonder what effect
it will have on the currently installed git-based packages. They are
already 1.0.26+gitxxxx, and they will remain so after this release
(though the xxxx part will be of a different format).

allan

On Thu, May 11, 2017 at 7:36 AM, Olaf Meeuwissen
Post by Olaf Meeuwissen
Hi all,
This is something that I've been wondering about for a while and with
the release coming up I thought I'd vent my thoughts/preferences on the
version numbering of sane-backends (and sane-frontends if we should ever
get around to releasing a new version of that).
Post by Rolf Bensch
Hi James,
Rolf,
Thanks for getting your ppa back up and running. However, I am not able
to install the libsane package using apt, even when I try to force the
version. I believe that your new version numbering with ~ is causing
the problem.
ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver
libsane-common=$versane-utils=$ver
1.0.26~this < 1.0.26 < 1.0.26+that
I don't recall the details for RPM-based distributions re ~ (note that
1.0.26 < 1.0.26+that
[1] https://fedoraproject.org/wiki/Packaging:Versioning
The problem with the way we currently do the versioning of sane-backends
is that we bump the version to what we *think* will be the next version.
This would work for Debian-based distribution packages if they use a ~
suffix to our version. For RPM-based distributions I don't know what
works. It also causes confusing bug reports and mails to the list where
people talk about using an upcoming release.
To fix that, can we agree to a version number for HEAD on master that
refers to the last *released* version? Something like this
1.0.26+git
for anything *after* the 1.0.26 release. This should work for all folks
rolling binary packages and indicates very clearly that it's 1.0.26 plus
a bunch of edits.
Actually, we may also want to look into using the output of
git describe
When I run this on my current checkout of master, I get
RELEASE_1_0_25-552-ge6711c3
This is <tag>-<number-of-commits-since-tag>-g<commit-ish>, so this
should work fine as long as people are using master. The number of
commits since the tag will sort later commits in the right order.
# We haven't used branches much so far, so this would be a reasonably
# safe assumption. Anyway, if you're using any other branch, I would
# assume you know what you're doing ;-)
If we also switch tags to use the version number as is, that would
become
1.0.25-552-ge6711c3
# Debian-based distributions may need to replace the - with something
# else. Using `sed 's/-/+/g'` or something similar should work.
Summarizing, let's use
<last-*released*-version>+git
from the 1.0.26 release onwards and look into using the output from `git
describe` to get an even better idea of what people are really running
when compiling from git.
How's that sound?
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-13 03:10:24 UTC
Permalink
Raw Message
Hi Allan,
Post by m. allan noah
this sounds like a reasonable plan to me, though I wonder what effect
it will have on the currently installed git-based packages. They are
already 1.0.26+gitxxxx, and they will remain so after this release
(though the xxxx part will be of a different format).
Most of the cases I've seen use a date for the xxx part. If so, there'd
be no problem as the git snapshots after the 1.0.26 release will have a
later date.

Distributions can also work around with an "epoch", so you get something
like "1:1.0.26+gitxxxx", but that's a bit ugly.

But we could also just admit that we've more or less goofed up on the
versioning for our master branch, skip 1.0.26 and release as 1.0.27.
Doing so will bypass any of the scenarios you worry about.

I'd go with 1.0.27 but am fine with 1.0.26 for the release and add a
+git on master (for now while we investigate using `git describe`).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Rolf Bensch
2017-05-13 09:12:53 UTC
Permalink
Raw Message
Hi All,

After reactivating my Ubuntu ppa it uses for the recent version
1.0.26~ppa[date].

OK, this breaks the old version from last July (1.0.26+git[date]), but I
communicated 2 instructions how the users can jump onto the new versions.

Don't worry about the Ubuntu distribution versions. They're still using
1.0.25+git20150528.

Using 'git describe' is an good idea. But please don't forget that we
must be able to compile the tarballs provided from sane's website and
alioth *without* installed git packages or with the correct version.

A header file (e.g. git-describe.h) could be a solution, which holds the
git version and has been created before creating the tarballs. If we're
compiling against a git repository, this file can be rewritten from
'make' and must be excluded from the git repository.

Hope this helps.

Cheers,
Rolf
Post by Olaf Meeuwissen
Hi Allan,
Post by m. allan noah
this sounds like a reasonable plan to me, though I wonder what effect
it will have on the currently installed git-based packages. They are
already 1.0.26+gitxxxx, and they will remain so after this release
(though the xxxx part will be of a different format).
Most of the cases I've seen use a date for the xxx part. If so, there'd
be no problem as the git snapshots after the 1.0.26 release will have a
later date.
Distributions can also work around with an "epoch", so you get something
like "1:1.0.26+gitxxxx", but that's a bit ugly.
But we could also just admit that we've more or less goofed up on the
versioning for our master branch, skip 1.0.26 and release as 1.0.27.
Doing so will bypass any of the scenarios you worry about.
I'd go with 1.0.27 but am fine with 1.0.26 for the release and add a
+git on master (for now while we investigate using `git describe`).
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-13 09:42:41 UTC
Permalink
Raw Message
Hi Rolf,

Thanks for chiming in.
Post by Rolf Bensch
Hi All,
After reactivating my Ubuntu ppa it uses for the recent version
1.0.26~ppa[date].
OK, this breaks the old version from last July (1.0.26+git[date]), but I
communicated 2 instructions how the users can jump onto the new versions.
Don't worry about the Ubuntu distribution versions. They're still using
1.0.25+git20150528.
There more to the world than Ubuntu, we live in a multiverse ;-P
Post by Rolf Bensch
Using 'git describe' is an good idea. But please don't forget that we
must be able to compile the tarballs provided from sane's website and
alioth *without* installed git packages or with the correct version.
Don't worry, I'm aware of that. I was thinking along the lines of
replacing the version number in configure{,.ac} with the "massaged"
output of `git describe` for the tarballs. I vaguely remember there
being a macro in gnulib that may help with this. But I'll do some more
research before implementing this.

No-one should be needing git or any of the autotools to build from our
source tarballs.
Post by Rolf Bensch
A header file (e.g. git-describe.h) could be a solution, which holds the
git version and has been created before creating the tarballs. If we're
compiling against a git repository, this file can be rewritten from
'make' and must be excluded from the git repository.
That would only work for source code. There are other places where we
may want to use version information, documentation for example.
Post by Rolf Bensch
Hope this helps.
Yup, and I hope this helps too,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Johannes Meixner
2017-05-15 08:29:49 UTC
Permalink
Raw Message
Hello,
They are already 1.0.26+gitxxxx,
Simply put:
A version number like 1.0.26+gitxxxx should have never
been used for somethig after 1.0.25 but before 1.0.26
because 1.0.26+gitxxxx means that it is after 1.0.26.
I.e. 1.0.26+gitxxxx is wrong, cf. my explanation below
about Ghostscript release candidates where the
Ghostscript upstream release candidate version number
is also just wrong like 9.15rc1 for the first release
candidate of the upcoming Ghostscript 9.15 release.
Distributions can also work around with an "epoch",
so you get something like "1:1.0.26+gitxxxx",
but that's a bit ugly.
at least not at openSUSE because here RPM "epoch" stuff
is "forbidden by policy".
I don't know the exact reasons behind but at last one reason
is - as far as I know - that once you have set an "epoch"
yon could never ever get rid of it later.
I.e. basically introducing "epoch" is like introducing
a leading "absolute maximum" part of the version i.e. a switch
from "major.minor.patchlevel" to "epoch.major.minor.patchlevel".
But we could also just admit that we've more or less
goofed up on the versioning for our master branch,
skip 1.0.26 and release as 1.0.27.
Doing so will bypass any of the scenarios you worry about.
Yes, please skip 1.0.26 and release as 1.0.27.
This is simple, fail safe, and avoids needless complications.


FYI:
Im general regarding how to keep strictly growing
version numbers, here some exceprts from the openSUSE
ghostscript.spec file that explain how correct version numbers
for intermediate stuff after version 1.2.3. like Git snapshots
or release candidates for a next version 1.3.0 should look like:
-----------------------------------------------------------------
# Special version needed for Ghostscript release candidates
# (e.g. "Version: 9.14pre15rc1" for 9.15rc1).
# Version 9.15rc1 would be newer than 9.15
# (run "zypper vcmp 9.15rc1 9.15")
# because the rpmvercmp algorithm
# would treat 9.15rc1 as 9.15.rc.1
# (alphabetic and numeric sections get separated
# into different elements)
# and 9.15.rc.1 is newer than 9.15
# (it has one more element in the list while
# previous elements are equal)
# so that we use an alphabetic prefix 'pre'
# to make it older than 9.15
# (numbers are considered newer than letters).
# But only with the alphabetic prefix "9.pre15rc1"
# would be older than the previous version number "9.14"
# because rpmvercmp would treat 9.pre15rc1 as 9.pre.15.rc1
# and letters are older than numbers
# so that we keep additionally the previous version number
# to upgrade from the previous version:
Version: 9.14pre15rc1
-----------------------------------------------------------------
This way users can "just upgrade" from Ghostscript release 9.14
to intermediate Ghostscript release candidates like 9.14pre15rc1
and further to 9.14pre15rc2 and 9.14pre15rc3 as they like and
finally to the next Ghostscript release 9.15.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-15 12:28:59 UTC
Permalink
Raw Message
Hi Johannes,
Post by Johannes Meixner
Hello,
They are already 1.0.26+gitxxxx,
A version number like 1.0.26+gitxxxx should have never
been used for somethig after 1.0.25 but before 1.0.26
because 1.0.26+gitxxxx means that it is after 1.0.26.
I.e. 1.0.26+gitxxxx is wrong, cf. my explanation below
about Ghostscript release candidates where the
Ghostscript upstream release candidate version number
is also just wrong like 9.15rc1 for the first release
candidate of the upcoming Ghostscript 9.15 release.
Various project use various conventions. For distributors this sucks
because it is well nigh impossible to come up with a version comparison
algorithm that works for all the software they want to package.

The case of 1.0.26+gitxxxx was not of the SANE project's making although
we surely gave the wrong impression with our 1.0.26git.
Post by Johannes Meixner
Distributions can also work around with an "epoch",
so you get something like "1:1.0.26+gitxxxx",
but that's a bit ugly.
at least not at openSUSE because here RPM "epoch" stuff
is "forbidden by policy".
I don't know the exact reasons behind but at last one reason
is - as far as I know - that once you have set an "epoch"
yon could never ever get rid of it later.
I.e. basically introducing "epoch" is like introducing
a leading "absolute maximum" part of the version i.e. a switch
from "major.minor.patchlevel" to "epoch.major.minor.patchlevel".
Correct. There's no way you can get rid of an epoch. It's a last
resort. It should be avoided as much as possible.
Post by Johannes Meixner
But we could also just admit that we've more or less
goofed up on the versioning for our master branch,
skip 1.0.26 and release as 1.0.27.
Doing so will bypass any of the scenarios you worry about.
Yes, please skip 1.0.26 and release as 1.0.27.
This is simple, fail safe, and avoids needless complications.
Thanks for agreeing with me. Let's try to keep our versioning sane, pun
intended, so distributors don't have to resort to all kinds of exotic
trickery to make upgrades work.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
James Duvall
2017-05-09 20:06:02 UTC
Permalink
Raw Message
Rolf,
OK, now it makes more sense to me.  I saw that the last released version was 1.0.25, but I didn't fully comprehend that your ppa is a pre-release for 1.0.26.  When 1.0.26 is released, of course you would want these builds to compare earlier than the released version.
One thing I still don't fully comprehend.  libsane=1.0.26~preXXX depends on libsane-common=1.0.26~preXXX, but libsane=1.0.26~preXXX also breaks libsane-common<<1.0.26
This seems like a conflict.  Isn't this saying that libsane breaks the same version that it depends on?
Sorry if I am being frustrating or dense on this topic.  As I understand, apt and dpkg won't allow 2 different versions of the same package to be simultaneously installed.  If the pre-release libsane requires a specific version of libsane-common, doesn't that automatically imply that it breaks/conflicts with any other version?  libsane=1.0.26~preXXX will also break 1.0.27 or 1.1 or anything else that is released in the future, right?
Using your instructions, I still can't install using apt, dpkg.  I installed synaptic, but I get the same error and refusal to install ().  I am running yakkety, so maybe there is some difference from trusty.

However, this is not a big problem for me.  I am able to automatically build from the sane-backends package on your ppa, so I can test my MG5420 with the latest fixes.  I'll send another email once I have verified all functions and the scanbd script you sent me.
Many thanks,James
On Tuesday, May 9, 2017 11:36 AM, Rolf Bensch <***@bensch-online.de> wrote:


Hi James,
Post by James Duvall
Rolf,
Thanks for getting your ppa back up and running.  However, I am not able
to install the libsane package using apt, even when I try to force the
version.  I believe that your new version numbering with ~ is causing
the problem.
ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver
libsane-common=$versane-utils=$ver
I used synaptic for Trusty and it's working.

You can use an alternative more complex procedure to get the updates
from my ppa:

(1) search for installed SANE packages:
$ dpkg -l *sane*

(2) purge all SANE packages with the version '1.0.26[-+]ppa{date}
*without* removing dependent packages:
$ sudo dpkg --force-all -P libsane libsane-common sane-utils [other
installed packages]

(3) reinstall SANE:
$ apt-get -f install

(4) reinstall all other removed packages, e.g.:
$ sudo apt-get install libsane-dev
Post by James Duvall
Apt complains that
  libsane : Breaks: libsane-common (< 1.0.26)
            Breaks: libsane-common:i386 (< 1.0.26)
E: Unable to correct problems, you have held broken packages.
I think the issue is that version 1.0.26~ppa20170508-yakkety0 compares
less than 1.0.26 due to special rules for handling ~ in version
dpkg --compare-versions 1.0.26~ppa20170508-yakkety0 lt 1.0.26 && echo true
true
This is correct. SANE 1.0.26 isn't released yet.
Inspired from your comment I renamed the version in my ppa to
'1.0.26~pre{date}'. This makes it more transparent that this is a
pre-release.
Post by James Duvall
I created a local repository and re-packaged as version
1.0.26+ppa20170508-yakkety0 and was able to install with no problems, so
maybe change the ~ for + or some other separator?  I am not experienced
with debian package management, so please disregard if I am missing
something.
Then you'll get the next update after we started the development of SANE
version 1.0.27, then AKA version 1.0.27~pre{date} from my ppa repository

Many thanks for your report.

Hope this helps.

Cheers,
Rolf
Rolf Bensch
2017-05-10 09:39:02 UTC
Permalink
Raw Message
Hi James,

I just found the problem in the build control file. Please test the
recent version from my ppa again.

Many thanks for your help.

Cheers,
Rolf
Rolf,
OK, now it makes more sense to me. I saw that the last released version
was 1.0.25, but I didn't fully comprehend that your ppa is a pre-release
for 1.0.26. When 1.0.26 is released, of course you would want these
builds to compare earlier than the released version.
One thing I still don't fully comprehend. libsane=1.0.26~preXXX depends
on libsane-common=1.0.26~preXXX, but libsane=1.0.26~preXXX also breaks
libsane-common<<1.0.26
This seems like a conflict. Isn't this saying that libsane breaks the
same version that it depends on?
Sorry if I am being frustrating or dense on this topic. As I
understand, apt and dpkg won't allow 2 different versions of the same
package to be simultaneously installed. If the pre-release libsane
requires a specific version of libsane-common, doesn't that
automatically imply that it breaks/conflicts with any other version?
libsane=1.0.26~preXXX will also break 1.0.27 or 1.1 or anything else
that is released in the future, right?
Using your instructions, I still can't install using apt, dpkg. I
installed synaptic, but I get the same error and refusal to install ().
I am running yakkety, so maybe there is some difference from trusty.
However, this is not a big problem for me. I am able to automatically
build from the sane-backends package on your ppa, so I can test my
MG5420 with the latest fixes. I'll send another email once I have
verified all functions and the scanbd script you sent me.
Many thanks,
James
Hi James,
Rolf,
Thanks for getting your ppa back up and running. However, I am not able
to install the libsane package using apt, even when I try to force the
version. I believe that your new version numbering with ~ is causing
the problem.
ver=1.0.26~ppa20170508-yakkety0; sudo apt-get install libsane=$ver
libsane-common=$versane-utils=$ver
I used synaptic for Trusty and it's working.
You can use an alternative more complex procedure to get the updates
$ dpkg -l *sane*
(2) purge all SANE packages with the version '1.0.26[-+]ppa{date}
$ sudo dpkg --force-all -P libsane libsane-common sane-utils [other
installed packages]
$ apt-get -f install
$ sudo apt-get install libsane-dev
Apt complains that
libsane : Breaks: libsane-common (< 1.0.26)
Breaks: libsane-common:i386 (< 1.0.26)
E: Unable to correct problems, you have held broken packages.
I think the issue is that version 1.0.26~ppa20170508-yakkety0 compares
less than 1.0.26 due to special rules for handling ~ in version
dpkg --compare-versions 1.0.26~ppa20170508-yakkety0 lt 1.0.26 && echo true
true
This is correct. SANE 1.0.26 isn't released yet.
Inspired from your comment I renamed the version in my ppa to
'1.0.26~pre{date}'. This makes it more transparent that this is a
pre-release.
I created a local repository and re-packaged as version
1.0.26+ppa20170508-yakkety0 and was able to install with no problems, so
maybe change the ~ for + or some other separator? I am not experienced
with debian package management, so please disregard if I am missing
something.
Then you'll get the next update after we started the development of SANE
version 1.0.27, then AKA version 1.0.27~pre{date} from my ppa repository
Many thanks for your report.
Hope this helps.
Cheers,
Rolf
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Loading...