Re: Debian part of a version number when epoch is bumped

[Guillem Jover]

Hi!

Given that other parts of the original thread have started to repeat
the same that has been discussed in previous referenced discussions,
or even within this thread iteration, I've sat down and written a
dpkg FAQ entry:

  


This subthread though, prompted me to come up with something new
though. :)

On Wed, 2018-02-14 at 12:54:05 -0800, Russ Allbery wrote:
> Michael Stone  writes:
> > That doesn't matter. The fundamental problem was that it's impossible to
> > predict that a future package would have an older version of the
> > software with a newer name. Whether that's done with an epoch that
> > (horrors!) won't go away or because someone creates a crazy version
> > string that obfuscates what's being done (yay?), the unpredictable
> > breakage is the same. The solution isn't to get rid of epochs, the
> > solution is to not create packages which contain older versions of
> > software with newer names.

> Not that this is probably easily fixable at this point, but mulling on
> this a bit, I think it's because we actually have two version orderings
> that we're compressing into one ordering.

This only covers the revert case, for which epochs are really the
wrong tool. To me this looks like the equivalent of using nukes as
a town planning strategy. :)

An epoch states that the previous version-line is no longer valid
and cannot be used or relied on anymore going forward.

> We want to do two things here:
> 
> * Give a package a larger version number so that the archive knows that it
>   replaces the previous version of the package and so that clients know
>   that this package should be installed in preference to the previous
>   version.
> 
> * Express versioned dependencies in other packages, allowing you to say
>   that you need at least version 1.8 of a package and 1.6 will not
>   suffice.

For a revert the only things we really need is to make the archive
accept lower versions, and for the package managers to accept a version
downgrade as the correct "upgrade" path. In this case preserving all
the versioned dependencies/checks intact is what we'd want anyway.

> Since there are two goals, a more correct implementation would be to split
> these into two versions.  The simplest would be to have an integer
> "version epoch" field in the package metadata separate from the version
> number.  So instead of:
> 
> Version: 1.8-1
> 
> Version: 1:1.6-1
> 
> you'd have:
> 
> Version: 1.8-1
> 
> Version: 1.6-1
> Epoch: 1

I don't think splitting this into a new field would fix much, it would
just complicate things. We already had the packaging revision in
separate fields (Package_Revision, Package-Revision, Revision) long time
ago, and it got eventually folded in. :)

I think there are two ways to fix the revert problem properly:

  * Create a new archive suite with some suite-specific metadata denoting
that whatever appears in this suite has a higher pin than anything
installed, and can thus downgrade packages (following the example
of the existing NotAutomatic repo fields). You could then have:

  pkg-a_1.0-1 (sid) → pkg-a_2.0-1 (sid) → pkg-a_1.0-2 (sid-revert)

Of course one problem is that this might perhaps require for
example new apt sources entries.

  * Add a new field, which specifies this is a revert and as such a
downgrade is expected. Then the package managers would know this
is the correct "upgrade" path. For example, say:

   Version: 1.0-1

   Version: 2.0-1

   Version: 2.0-2

   Version: 1.0-2
   Reverts: 2.0-2

Perhaps, even allowing relationships in the field, dunno:

   Reverts: >= 2.0-1, <= 2.0-2

Thanks,
Guillem

Work-needing packages report for Feb 16, 2018

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1262 (new: 3)
Total number of packages offered up for adoption: 164 (new: 1)
Total number of packages requested help for: 52 (new: 2)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   hyperestraier (#890502), orphaned today
 Description: full-text search system for communities
 Reverse Depends: hyperestraier libestraier-dev libestraier-java
   libestraier-perl ruby-hyperestraier
 Installations reported by Popcon: 318
 Bug Report URL: http://bugs.debian.org/890502

   qdbm (#890504), orphaned today
 Description: QDBM Database
 Reverse Depends: hyperestraier libestraier-dev libestraier-java
   libestraier-perl libestraier8 libqdbm++-dev libqdbm-dev libqdbm-java
   libqdbm-perl libqdbm3++c2 (11 more omitted)
 Installations reported by Popcon: 48937
 Bug Report URL: http://bugs.debian.org/890504

   xcompmgr (#890196), orphaned 4 days ago
 Description: X composition manager
 Installations reported by Popcon: 967
 Bug Report URL: http://bugs.debian.org/890196

1259 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   oregano (#890503), offered today
 Description: tool for schematical capture of electronic circuits
 Installations reported by Popcon: 919
 Bug Report URL: http://bugs.debian.org/890503

163 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] pdf-redact-tools (#890328), requested 2 days ago
 Description: PDF Redact Tools helps with securely redacting and
   stripping
 Installations reported by Popcon: 17
 Bug Report URL: http://bugs.debian.org/890328

[NEW] qalculate-gtk (#890272), requested 3 days ago
 Description: Powerful and easy to use desktop calculator - GTK+
   version
 Reverse Depends: qalculate
 Installations reported by Popcon: 1261
 Bug Report URL: http://bugs.debian.org/890272

   autopkgtest (#846328), requested 442 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 1102
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2335 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 673
 Bug Report URL: http://bugs.debian.org/642906

   broadcom-sta (#886599), requested 38 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 2040
 Bug Report URL: http://bugs.debian.org/886599

   cargo (#860116), requested 310 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 574
 Bug Report URL: http://bugs.debian.org/860116

   cups (#532097), requested 3176 days ago
 Description: Common UNIX Printing System
 Reverse Depends: ayatana-indicator-printers bluez-cups boomaga
   chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd (69 more omitted)
 Installations reported by Popcon: 181296
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 876 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (123 more omitted)
 Installations reported by Popcon: 203662
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 580 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 65736
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1265 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 14656
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 870 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian bzr

Re: How to report bugs with the new git repo?

[Sean Whitton]

Hello Pavlo,

On Thu, Feb 15 2018, Pavlo Solntsev wrote:

> I am very excited to see that Debian has moved to GitLab (
> https://salsa.debian.org). With this change, I am wondering how bug
> report process should look like? Now, I want to submit patches to
> packages, e.g.  libgdamm. What would be the best process: submit a
> patch via push request in the Debian repo, or push patches to
> upstream?

Your choices are basically:

- send a patch to the bug as before, ideally adding the patch tag, with
  patch attached

- send an e-mail to the bug, ideally adding the patch tag, including a
  URI to your merge request.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: How to report bugs with the new git repo?

[Pavlo Solntsev]

OK,
it looks like it is clear. Thanks.


-Pavlo Solntsev

-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
*

On Thu, Feb 15, 2018 at 11:35 AM, Mattia Rizzolo  wrote:

> On Thu, Feb 15, 2018 at 08:24:21PM +0500, Andrey Rahmatullin wrote:
> > If the question is "how should I send a patch to the maintainer" then a
> > pull request is just one of the available ways, and the best one was
> > always opening a bug report in the BTS, sending the changes in some other
> > way directly to the maintainer was always possible too.
>
> On this note, consider that I'm not sure people have realized they need
> to subscribe ("watch") the gitlab project to receive notifications about
> new MRs.
>
> At least I already encountered two maintainers who didn't and miss some
> MRs until poked elsewhere.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Bug#890540: ITP: libtest-postgresql-perl -- sets up and destroys temporary PostgreSQL instances for testing

[Don Armstrong]

Package: wnpp
Owner: Don Armstrong 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-postgresql-perl
  Version : 1.23
  Upstream Author : Toby Corkindale Kazuho Oku Peter Mottram plus various 
contributors.
* URL : https://metacpan.org/release/Test-PostgreSQL
* License : Artistic-2.0
  Programming Lang: Perl
  Description : sets up and destroys temporary PostgreSQL instances for 
testing

Test::PostgreSQL automatically setups a PostgreSQL instance in a temporary
directory, and destroys it when the perl script exits.

Test::PostgreSQL is a fork of Test::postgresql, which was abandoned by its
author several years ago.

The package will be maintained under the umbrella of the Debian Perl Group.

-- 
Don Armstrong  https://www.donarmstrong.com

Rule 30: "A little trust goes a long way. The less you use, the
further you'll go."
  -- Howard Tayler _Schlock Mercenary_ March 8th, 2003
 http://www.schlockmercenary.com/d/20030308.html

Re: How to report bugs with the new git repo?

[Mattia Rizzolo]

On Thu, Feb 15, 2018 at 08:24:21PM +0500, Andrey Rahmatullin wrote:
> If the question is "how should I send a patch to the maintainer" then a
> pull request is just one of the available ways, and the best one was
> always opening a bug report in the BTS, sending the changes in some other
> way directly to the maintainer was always possible too.

On this note, consider that I'm not sure people have realized they need
to subscribe ("watch") the gitlab project to receive notifications about
new MRs.

At least I already encountered two maintainers who didn't and miss some
MRs until poked elsewhere.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: How to report bugs with the new git repo?

[Ole Streicher]

"W. Martin Borgert"  writes:
> If it is (probably) a Debian bug, submit bug (and patch) to the
> Debian BTS. Ideally, using the "reportbug" command.

I would prefer a merge request over a bug with an attached patch: the
gitlab workflow is quite effective, especially when compared to a
(randomly formatted) patch file. And I also like that the patch author
is automatically attributed when the patch is accepted.

Is it possible to setup a gitlab hook that automatically generates a
"patch" tagged bug report when a merge request is created?

Cheers

Ole

Bug#890523: ITP: python3-anosql -- A Python library for using SQL

[Florian Grignon]

Package: wnpp
Severity: wishlist
Owner: Florian Grignon 

* Package name: python3-anosql
  Version : 0.2.0
  Upstream Author : Honza Pokorny 
* URL : https://github.com/honza/anosql
* License : BSD
  Programming Lang: Python
  Description : A Python library for using SQL

A Python library for using SQL.
Inspired by the excellent Yesql library by Kris Jenkins. In my mother
tongue, ano means yes.

This Python library is becoming popular amoung the Python community
working with PostgreSQL and SQLite. This library has currently
(15/02/2018) 66 stars github, and is referenced in some books (like
MasteringPostgreSQL from Dimitry Fontaine). The library is simple and
small. It is tested on Travis CI, and has a github repository
https://github.com/honza/anosql.

I am an experienced Python web developper, and I use this library in
small personnal project, alongside Flask and psycopg2. This is, from
these three libraries the only one I'm packaging myself with the pybuild
buildsystem. I took example on the Flask packaging system and it works
like a charm out of the box.

This library is a very small library that helps Python project to use
raw SQL queries. This can be seen as a competitor of ORM. And as
performance becomes more and more important with the size of a Python
project, the need to use raw SQL instead of ORM becomes inevitable.
Raw SQL queries also gives much more flexibility and features to the
developper compared to the ORM.

This library doesn't have any dependencies. It can be used alongside
psycopg2 for PostgreSQL or sqlite for SQLite databases engine.

As a full-time computer scientist, I have time to create and maintain it
on my professionnal and personnal time. I will search for a sponsor to
guide me through the steps of creating and maintaining a debian
packaging.

I'd like to include the package, in a second time, to the Debian Python
Module Team, and include myself to the team.

Re: How to report bugs with the new git repo?

[Andrey Rahmatullin]

On Thu, Feb 15, 2018 at 09:00:28AM -0600, Pavlo Solntsev wrote:
> I am very excited to see that Debian has moved to GitLab (
> https://salsa.debian.org). With this change, I am wondering how bug report
> process should look like? 
I don't think anything has changed.

>  Now, I want to submit patches to packages, e.g.
> libgdamm. What would be the best process: submit a patch via push request
> in the Debian repo, or push patches to upstream?
If the question is "whether I should send the changes to the upstream
authors or to the maintainer" then nothing has changed.
If the question is "how should I send a patch to the maintainer" then a
pull request is just one of the available ways, and the best one was
always opening a bug report in the BTS, sending the changes in some other
way directly to the maintainer was always possible too.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to report bugs with the new git repo?

[W. Martin Borgert]

Quoting Pavlo Solntsev :

Now, I want to submit patches to packages, e.g.
libgdamm. What would be the best process: submit a patch via push request
in the Debian repo, or push patches to upstream?


If it is (probably) a Debian bug, submit bug (and patch) to the
Debian BTS. Ideally, using the "reportbug" command.

If it is (probably) an upstream bug, submit the bug to upstream
in the form prefered by upstream.

Cheers

How to report bugs with the new git repo?

[Pavlo Solntsev]

Hello,

I am very excited to see that Debian has moved to GitLab (
https://salsa.debian.org). With this change, I am wondering how bug report
process should look like? Now, I want to submit patches to packages, e.g.
libgdamm. What would be the best process: submit a patch via push request
in the Debian repo, or push patches to upstream?

Thanks,

-Pavlo Solntsev
-

*Please avoid sending me Word or PowerPoint attachments.See
http://www.gnu.org/philosophy/no-word-attachments.html
*

Bug#890520: ITP: webext-privacy-badger -- Privacy Badger blocks spying ads and invisible trackers

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes 

* Package name: webext-privacy-badger
  Version : 2018.2.5
  Upstream Author : Electronic Frontier Foundation and other contributors
* URL : https://github.com/EFForg/privacybadger
* License : GPL v3+
  Programming Lang: JavaScript
  Description : Privacy Badger blocks spying ads and invisible trackers

Privacy Badger is a browser add-on that stops advertisers and other
third-party trackers from secretly tracking where you go and what pages you
look at on the web.  If an advertiser seems to be tracking you across multiple
websites without your permission, Privacy Badger automatically blocks that
advertiser from loading any more content in your browser.  To the advertiser,
it's like you suddenly disappeared.

Git has already been created for webext-team on salsa.

Michael

Bug#890519: ITP: intel-ipsec-mb -- Intel(R) Multi-Buffer Crypto for IPSec library

[Colin Ian King]

Package: wnpp
Severity: wishlist
Owner: Colin Ian King 

* Package name: intel-ipsec-mb
  Version : 0.48
  Upstream Author : tomasz.kante...@intel.com
* URL : https://github.com/intel/intel-ipsec-mb
* License : BSD-3-clause
  Programming Lang: C, assembler
  Description : Intel(R) Multi-Buffer Crypto for IPSec library

 Libipsec-mb is highly-optimized software implementations of
 the core cryptographic processing for IPsec, which provides
 industry-leading performance on a range of Intel(R) Processors.

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

Le 15/02/2018 à 14:15, Vincent Bernat a écrit :

  ❦ 15 février 2018 13:36 +0100, Thibaut Paumard  :


I meant not implemented for java, specifically. But I was wrong: we do
have e.g. java8-runtime-headless listed in
https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

So the package mentioned by Vincent may be better off Depending on it
rather than on default-jre-headless (>= anything).


You cannot depend on a virtual package, am I wrong?


You can. The problem is when your package may be used as a 
build-dependency within the Debian infrastructure:


https://lintian.debian.org/tags/virtual-package-depends-without-real-package-depends.html

Regards, Thibaut.

Re: Debian part of a version number when epoch is bumped

[Vincent Ladeuil]

> Simon McVittie  writes:

> 3.1
> 3.11
> 95
> 98
> 2000
> 1:5.1+XP # or 2001+XP or something
> 1:5.2+Vista  # or 2006+Vista or something
> 1:7
> 1:8
> 1:8.1
> 1:10

> Ignoring the epoch would be actively harmful here: if you have a versioned
> dependency on Windows >= 8, it would be incorrect for Windows 95 to
> satisfy that dependency.

At that moment, /me was enlightened.

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Thu, Feb 15, 2018 at 10:58:01AM +0100, Thibaut Paumard wrote:

Well, in retrospect it would have been good to declare:

Depends: default-jre-headless (>= 1:1.8), default-jre-headless (<< 2:)


Honestly, the best thing would have just been to depend on 
openjdk-8-jre-headless instead of messing around with 
default-jre-headless.


Michael Stone

Re: Debian part of a version number when epoch is bumped

[Vincent Bernat]

 ❦ 15 février 2018 13:36 +0100, Thibaut Paumard  :

> I meant not implemented for java, specifically. But I was wrong: we do
> have e.g. java8-runtime-headless listed in
> https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
>
> So the package mentioned by Vincent may be better off Depending on it
> rather than on default-jre-headless (>= anything).

You cannot depend on a virtual package, am I wrong? I still need a
concrete alternative. That's the purpose of default-jre-headless. Note
this was an example about epoch. I don't pretend wanting to fix how to
package OOT Java packages.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#890510: ITP: gnome-usage -- simple system monitor app for GNOME

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
Owner: jbi...@debian.org

Package Name: gnome-usage
Version: 3.27.90
Upstream Authors : Red Hat, Felipe Borges
License : GPL-3+, parts are LGPL-2.1+ or LGPL-3+
Programming Lang: Vala, C
Homepage: https://wiki.gnome.org/Apps/Usage

Description: simple system monitor app for GNOME
 Usage is an application for GNOME that allows monitoring of system resources
 such as memory, CPU, and disk space.

Other Info
--
This is the first release of GNOME Usage. I think the intent is for
this app to replace Disk Usage Analyzer (baobab), GNOME System
Monitor, and GNOME Power Statistics (gnome-power-manager) in core
GNOME in a future GNOME release.

But baobab and gnome-system-monitor may continue to be maintained to
provide more powerful features. GNOME Usage doesn't provide power
statistics yet.

Packaging is at
https://salsa.debian.org/gnome-team/gnome-usage

Thanks,
Jeremy Bicha

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

Le 15/02/2018 à 13:03, gregor herrmann a écrit :

On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote:


The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds
also neat for java packages, but it does not seem to be implemented.


It's '(= $version') and we do have these versioned Provides since a
couple of years [0], they just haven't made their way into Policy
yet: https://bugs.debian.org/761219



Thanks.

I meant not implemented for java, specifically. But I was wrong: we do 
have e.g. java8-runtime-headless listed in

https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

So the package mentioned by Vincent may be better off Depending on it 
rather than on default-jre-headless (>= anything).


Kind regards, Thibaut.

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

(Please follow-up to debian-curiosa)

Le 15/02/2018 à 11:41, Simon McVittie a écrit :


We don't have to look far to find a weird versioning scheme that can't
be represented without epochs: our largest competitor in the field of
general-purpose operating systems has such a versioning scheme. Imagine
we had a package that followed the same versioning scheme as Windows (I
could imagine a parallel universe in which Wine used the version number
of the version of Windows that it claims to emulate). If we packaged
that, using the "marketing version" wherever it's numeric or making up
something reasonable wherever it isn't, we might have had a versioning
scheme like this:


Well, as it happens, all the Windows versions also have a number that 
sorts properly, but does not always match the commercial number:





3.1
3.11
95


4.00


98


4.10


2000


NT 5.0 (which we could have translated as 5.0+NT, for instance)


1:5.1+XP # or 2001+XP or something


NT 5.1 (5.1+NT)


1:5.2+Vista  # or 2006+Vista or something


NT 6.0


1:7


Funnily, this is NT 6.1!


1:8


NT 6.2


1:8.1


NT 6.3


1:10


NT 10.0

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Re: Debian part of a version number when epoch is bumped

[gregor herrmann]

On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote:

> The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds
> also neat for java packages, but it does not seem to be implemented.

It's '(= $version') and we do have these versioned Provides since a
couple of years [0], they just haven't made their way into Policy
yet: https://bugs.debian.org/761219


Cheers,
gregor

[0] Maybe not in all corners of the debiverse yet;
ci.debian.net/autopkgtest is, TTBOMK, the last issue:
https://bugs.debian.org/867081

One of the last fixed issues:
https://bugs.debian.org/867104

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #388:  Bad user karma. 

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Thu, Feb 15, 2018 at 10:41:23AM +, Simon McVittie wrote:
> On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> > I was thinking it might be better to go to a "wildcard" epoch:
> > 
> > Depends: X (>= *:1.8)
> > 
> > would mean
> > 
> > "For this comparison, ignore the epoch, and make sure that the version
> > is at least 1.8 or above".
> 
> This would work for the "oops, that was meant to go to experimental"
> case where +really also gets used, but would do the wrong thing for the
> original purpose of epochs, which is dealing with upstream version
> numbering that doesn't match dpkg semantics.

Which would mean that in that case, the dependency should not be
declared as "X (>= *:1.8)", but instead as "X (>= 1:1.8)".

(We might at some point discover that we want to update the whole scheme
so it also supports "X (>= [1-*]:1.8)" to cover a combination of the two
cases that you and I just described, but really?)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Simon McVittie]

On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> I was thinking it might be better to go to a "wildcard" epoch:
> 
> Depends: X (>= *:1.8)
> 
> would mean
> 
> "For this comparison, ignore the epoch, and make sure that the version
> is at least 1.8 or above".

This would work for the "oops, that was meant to go to experimental"
case where +really also gets used, but would do the wrong thing for the
original purpose of epochs, which is dealing with upstream version
numbering that doesn't match dpkg semantics.

For instance, if your upstream uses a date-based version number (20180215
or 18.01 or something) but later decides that they don't like that
version scheme and switches to 1.0, 1.1, ..., adding an epoch is the
only way to make such versions sort correctly (if you have predicted
this situation ahead of time, you can use versions like 0~20180215, but
epochs are precisely for the situation where you weren't able to predict
how upstream's version numbering would change). Helpful upstreams don't
do this, but not all upstreams are helpful, so general-purpose packaging
systems like dpkg and rpm need an "escape hatch" to cope.

We don't have to look far to find a weird versioning scheme that can't
be represented without epochs: our largest competitor in the field of
general-purpose operating systems has such a versioning scheme. Imagine
we had a package that followed the same versioning scheme as Windows (I
could imagine a parallel universe in which Wine used the version number
of the version of Windows that it claims to emulate). If we packaged
that, using the "marketing version" wherever it's numeric or making up
something reasonable wherever it isn't, we might have had a versioning
scheme like this:

3.1
3.11
95
98
2000
1:5.1+XP # or 2001+XP or something
1:5.2+Vista  # or 2006+Vista or something
1:7
1:8
1:8.1
1:10

Ignoring the epoch would be actively harmful here: if you have a versioned
dependency on Windows >= 8, it would be incorrect for Windows 95 to
satisfy that dependency.

smcv

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Wed, Feb 14, 2018 at 04:28:41PM -0500, Michael Stone wrote:
> On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote:
> > Since there are two goals, a more correct implementation would be to split
> > these into two versions.  The simplest would be to have an integer
> > "version epoch" field in the package metadata separate from the version
> > number.  So instead of:
> > 
> > Version: 1.8-1
> > 
> > Version: 1:1.6-1
> > 
> > you'd have:
> > 
> > Version: 1.8-1
> > 
> > Version: 1.6-1
> > Epoch: 1
> > 
> > We then could implement the separate semantics: only the version field
> > would be used for interpackage dependencies, so 1.6-1 with epoch 1 would
> > not satisfy >= 1.8 dependencies, but DAK and apt clients would know that
> > any package with epoch 1 supersedes packages with no epoch for archive and
> > default installation purposes.
> > 
> > Of course, getting to that from where we are now may be substantially more
> > trouble than it's worth, and it would necessarily be a very slow rollout
> > process (and there are still issues with unique filenames).
> 
> I don't think you'd need to change the package metadata for this, just
> change the comparison rules. I'm not entirely sure what the semantics should
> be, though--a simple depends >= is easy, but what about conflicts and breaks
> with <= *:1.8)

would mean

"For this comparison, ignore the epoch, and make sure that the version
is at least 1.8 or above".

Beyond that, the usual semantics of all the operators would apply. No
need for "special" operators or metadata format changes.

I was thinking for a moment that it might be useful to have that
implemented as a "general" thing, but then I cannot think of any
situation where a dependency of the form "any version of this package,
as long as it has a Debian revision of 2 or above" might be useful.
Given that, it might also be good to state that wildcard version
comparisons may not include the debian revision, only the upstream
version number.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote:
> Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> > On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> >> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> >> this will be true with X 1:1.6 as well.
> > Or with 1.8+really1.6.
> 
> But this problem will fix itself (after a release cycle at most). An
> epoch stays around forever.
> 
> From personal experience I've seen enough packages which declared a
> dependency on libfoo-dev (x.y) and forgot the epoch.

Then they get a bug filed and the problem is solved.

> epochs in library packages are extremely bad and should be avoided at
> all costs.

I can see why they might be confusing, and I can see why some people
prefer the +really approach, even though I think that's silly.

To go from there to "should be avoided at all costs" is a bit overdoing
it, though.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

Le 14/02/2018 à 18:52, Vincent Bernat a écrit :

More concrete example (now a bit in the past). On Wheezy, you want to
depend on a 1.8 JRE (you package independently). You put
default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the
epoch to both your own package version default-jre-headless (1:1.8-1)
and to the dependency. All good. You upgrade to Jessie and rebuild
everything. Jessie comes with default-jre-headless (2:1.7-52) which
shadows your default-jre-headless (1:1.8-1) package.



Dear Vincent,

Well, in retrospect it would have been good to declare:

Depends: default-jre-headless (>= 1:1.8), default-jre-headless (<< 2:)

when you first added the epoch to the Depends line. In general it's not 
easy to predict which future version of a package will actually break 
you package.


The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread 
sounds also neat for java packages, but it does not seem to be implemented.


What I don't quite understand: are you distributing your own 
default-jre-headless package, with a version later than the one in 
Debian? I'm not sure overriding a "default" package with a custom one is 
a good idea. That depends on the context of course.


In fact, one could argue that you should perhaps Depend on a specific 
JRE instead (or an bunch of JREs with | in between). But I understand 
you are just showing a real-life example where bumping the epoch caused 
headaches to "someone else".



Kind regards, Thibaut.

Bug#890492: ITP: node-localstorage -- substitute for the browser native localStorage API

[ju xor]

Package: wnpp
Severity: wishlist
Owner: ju xor 

* Package name: node-localstorage
  Version : 1.3.0
  Upstream Author : Larry Maccherone (http://maccherone.com)
* URL : https://github.com/lmaccherone/node-localstorage
* License : Expat
  Programming Lang: JavaScript
  Description : substitute for the browser native localStorage API


 A substitute for the node.js browser native localStorage API that
 runs on node.js
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency of OpenPGP JavaScript implementation,
which ITP is #787774.

This package should be maintained by the Debian Javascript team.
I'm not a memeber of the team.

Re: Debian part of a version number when epoch is bumped

[Adam Borowski]

On Thu, Feb 15, 2018 at 08:50:58AM +0100, gregor herrmann wrote:
> On Thu, 15 Feb 2018 08:45:23 +0100, Adam Borowski wrote:
> 
> > Package foo
> > Version: 2.0-really1.5-1
> > Provides: foo-api-1.5
> 
> Or:
> Provides: foo-api (= 1.5)

There is a difference -- some features might be added (usually backported)
to a stable branch of foo-1.5, so a depender may want foo-api-1.5 >= 1.5.42
as it has something that's missing or buggy in 1.5.41.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?