Bug#570623: reprepro: please add multiple version management

[Bastian Germann]

I am about to upload an experimental version with Benjamin's changes.
Please open new bugs for the issues that you may have with the new version even 
if they are already mentioned here.

Bug#570623: reprepro: please add multiple version management

[Kodiak Firesmith]

I’d love to see this merged.  It looks like Benjamin Drung put an absolute
mountain of work into getting this ready to merge, and that a lot of folks
have wanted this feature over the years.  

After more than 170 messages it’d be a shame to just see this feature die on
the vine.

- Kodiak

On Fri, 8 Jan 2021 21:13:48 +0100 Marek
=?utf-8?Q?Marczykowski-G=C3=B3recki?= 
wrote: 
> On Tue, 24 Mar 2020 15:36:39 +0100 Michael Prokop  wrote:

> > Hi, 
> > 
> > * Michael Prokop [Wed Jul 03, 2019 at 11:59:23AM +0200]: 
> > > * Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]: 
> > 
> > > > I refreshed the patches on top of version 5.3.0 and pushed it to 
> > > > https://salsa.debian.org/bdrung/reprepro/ and 
> > > > https://github.com/profitbricks/reprepro 
> > 
> > > Thanks for your efforts, Benjamin, highly appreciated. 
> 
> I have tested the above branch (mostly 'include' and 'export' commands) 
> and generally it works fine. I've found one weird corner case related to 
> updating from older reprepro (5.1.1, without the patches), possibly db 
> format: 
>  - packages that were in the db before update, are no longer included in 
>generated metadata ('export' command), unless added again with 
>'include' command 
>  - 'dumpreferences' _does_ include those missing packages 
> 
> It may be also that I'm missing some explicit db conversion step (I 
> haven't done anything, just updated reprepro package). 
> 
> -- 
> Best Regards, 
> Marek Marczykowski-Górecki 
> Invisible Things Lab 
> A: Because it messes up the order in which people normally read text. 
> Q: Why is top-posting such a bad thing? 



smime.p7s
Description: S/MIME cryptographic signature

Bug#570623: reprepro: please add multiple version management

[Marek Marczykowski-Górecki]

On Tue, 24 Mar 2020 15:36:39 +0100 Michael Prokop  wrote:
> Hi,
> 
> * Michael Prokop [Wed Jul 03, 2019 at 11:59:23AM +0200]:
> > * Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]:
> 
> > > I refreshed the patches on top of version 5.3.0 and pushed it to 
> > > https://salsa.debian.org/bdrung/reprepro/ and 
> > > https://github.com/profitbricks/reprepro
> 
> > Thanks for your efforts, Benjamin, highly appreciated.

I have tested the above branch (mostly 'include' and 'export' commands)
and generally it works fine. I've found one weird corner case related to
updating from older reprepro (5.1.1, without the patches), possibly db
format:
 - packages that were in the db before update, are no longer included in
   generated metadata ('export' command), unless added again with
   'include' command
 - 'dumpreferences' _does_ include those missing packages

It may be also that I'm missing some explicit db conversion step (I
haven't done anything, just updated reprepro package).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature

Bug#570623: reprepro: please add multiple version management

[Michael Prokop]

Hi,

* Michael Prokop [Wed Jul 03, 2019 at 11:59:23AM +0200]:
> * Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]:

> > I refreshed the patches on top of version 5.3.0 and pushed it to 
> > https://salsa.debian.org/bdrung/reprepro/ and 
> > https://github.com/profitbricks/reprepro

> Thanks for your efforts, Benjamin, highly appreciated.

> Bernhard, is there any specific reason why you didn't respond here
> any longer? Is there anything which would help to increase chances
> to get this feature merged in the near future?

Ping. :) Any news here?

regards
-mika-


signature.asc
Description: Digital signature

Bug#570623: reprepro: please add multiple version management

[Michael Prokop]

Hi,

* Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]:

> I refreshed the patches on top of version 5.3.0 and pushed it to 
> https://salsa.debian.org/bdrung/reprepro/ and 
> https://github.com/profitbricks/reprepro

Thanks for your efforts, Benjamin, highly appreciated.

Bernhard, is there any specific reason why you didn't respond here
any longer? Is there anything which would help to increase chances
to get this feature merged in the near future?

regards
-mika-


signature.asc
Description: Digital signature

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Am Sonntag, den 31.03.2019, 15:12 +0200 schrieb Vincent Bernat:
> Package: reprepro
> Version: 5.3.0-1
> Followup-For: Bug #570623
> 
> What is the status of this feature? The merge request is not
> available anymore

It seems that the support for pull requests were disabled.

>  and the GitHub repository of the fork is not up-to-date with
> 5.3.0.

I refreshed the patches on top of version 5.3.0 and pushed it to 
https://salsa.debian.org/bdrung/reprepro/ and 
https://github.com/profitbricks/reprepro

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#570623: reprepro: please add multiple version management

[Vincent Bernat]

Package: reprepro
Version: 5.3.0-1
Followup-For: Bug #570623

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

What is the status of this feature? The merge request is not available
anymore and the GitHub repository of the fork is not up-to-date with
5.3.0.

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reprepro depends on:
ii  libarchive13   3.3.3-4
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.28-8
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6
ii  liblzma5   5.2.4-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages reprepro recommends:
ii  apt  1.8.0

Versions of packages reprepro suggests:
ii  gnupg-agent  2.2.13-1
ii  gpg-agent [gnupg-agent]  2.2.13-1
pn  inoticoming  
pn  lzip 
ii  pinentry-curses  1.1.0-1+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlygvLwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5WUIP/3DY63Dao5HqvaXyiVG/Q1jLsn2YC7re
6miL77z5sDLHgtcbn8U2ObIdUvbnHvA7+4hvy6wl5lInxsHV0N5RlaeemiQ3LbYI
WVAYCgGbZNEy+80+sQ/1TorIn+Q/uTAeKMNrdnUT2hzuPTR7974mCdTBRI4a5ZXa
w1my8vBWMMHEgcX7hvcZ8gE/GujQF9HXL8SpA8n2yS4K1+9RoCUdWiPulbpYXc43
hSc0dgZ3mpIej7vJt5AtthtHhZssmMKDCW+43ciAO7ZlUMrG99Oji9q3GR1LTrkY
oIOSY6FVDm7pD7gbR+BRTfi1g1GP7uNCnWWVcntzgVzOZYJvbeEy6Wq3UY+MJhc0
DwX2aDYH8ehn/TyWWfNiKwUZcrOPDzK+Ki1iFQXJIYrnNqmdHVql9fsN8zh3ODPx
i418tDz9kXHs3LISJxA3f43I+53CpLL4OJQJKzu7VEfvz0F3RyQA27Sd761Xtjaq
twEsdYj9eXZbpmE41yIZl8cMK3vMGMFbDe7G7iOaAQPV/M7TL5LLa8S2fybGwNjS
St70JvMZUO7sQsh4nE9KW/nzeA2f+il5/jA6gGJ6fHEU6pIjklMCM2YcSdXkG4sk
NgNTkdL4pe+xbL+Wjjkc9fGhwpLvKFT+NROwrj7UHAfwY8xBR54x6tobRkhJPymH
/sllHO6/dL4l
=nCAm
-END PGP SIGNATURE-

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Hi everyone,

I rebased the patch set on top of the 5.2.0-1 release. Attached are all
71 patches as tarball. You can also pull the multiple-versions branch
from https://github.com/profitbricks/reprepro
Feel free to report bugs on GitHub.

Release Notes
=

Changes between 2017-04-12 and 2018-09-03:

* Rebased on 5.2.0
* Fix missing quotation mark in component list
* Fixed "Package database is not sorted!!!" by update command
  https://github.com/profitbricks/reprepro/issues/6
* Fixed screwing up database names by the database migration
  https://github.com/profitbricks/reprepro/issues/8
* Fix adding the same upstream tarball twice
  https://github.com/profitbricks/reprepro/issues/9
* Fix removesrc when multiple version are available

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens

multiple-versions-patches-5.2.0.tar.xz
Description: application/xz-compressed-tar

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Hi everyone,

I found some issues with my patch set from 2017-03-29 which I have
fixed with the new patch set as of yesterday. Attached are all 65
patches as tarball. You can also pull the 5.1.1-mutiple-versions branch
from https://github.com/profitbricks/reprepro
Feel free to report bugs on GitHub.

Release Notes
=

Changes between 2017-03-29 and 2017-04-12:

* Fix typo "could not found" -> "could not find" 
* Fix crash when Limit and Tracking is set
* Fix logging when using Archive option
* Fix tracking data when using move command
* Fix tracking data with Archive option
* Do not archive newly added packages (for downgrades)
* Use database environment to avoid database corruption
* Fix BDB0073 DB_NOTFOUND at del (when copying existing packages)

The test cases were enhanced to also check the tracking information and
some new tests were added.

In case you experience following error:
BDB0088 DB_SECONDARY_BAD: Secondary index inconsistent with primary
you can use the attached reconstruct_secondarydb Python script to
reconstruct the secondary database. (I had the issues that the sorting
of the secondary database was wrong and this inconsistency was only
revealed by the new Archive and Limit option)

In addition, dump_packages is attached to dump the content of the
packages.db and packagenames.db in a human readable format (useful to
compare the result of reconstruct_secondarydb).

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.#!/usr/bin/python3

# Copyright (C) 2017, Benjamin Drung 
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

"""Dump the content of packages.db and packagenames.db in human-readable format."""

import os

import debian.debian_support
import bsddb3

def get_package_name(primarykey, primarydata):
return primarykey.split(b'|')[0] + b'\0'


def debianversioncompare(a, b):
if a == '' and b == '':
# TODO: Find reason for this call!
return 0
a_version = debian.debian_support.Version(a.decode().rstrip('\0').split('|')[1])
b_version = debian.debian_support.Version(b.decode().rstrip('\0').split('|')[1])
if a_version < b_version:
return 1
elif a_version == b_version:
return 0
else:
return -1


packages_filename = 'packages.db' if os.path.isfile('packages.db') else 'db/packages.db'
packagenames_filename = 'packagenames.db' if os.path.isfile('packagenames.db') else 'db/packagenames.db'
packages = bsddb3.btopen(packages_filename, 'r')
databases = list(d.decode() for d in packages.keys())
packages.close()

for database in databases:
db = bsddb3.db.DB()
db.open(packages_filename, dbname=database, dbtype=bsddb3.db.DB_BTREE)
for key, value in db.items():
print("= {} | {} =\n{}".format(database, key.decode().strip('\0'),
   value.decode().strip('\0')))
db.close()

for database in databases:
sec_db = bsddb3.db.DB()
sec_db.set_flags(bsddb3.db.DB_DUPSORT)
sec_db.set_dup_compare(debianversioncompare)
sec_db.open(packagenames_filename, dbname=database, dbtype=bsddb3.db.DB_BTREE)
for key, value in sec_db.items():
print("{} | {} -> {}".format(database, key.decode().strip('\0'),
 value.decode().strip('\0')))
db.close()
#!/usr/bin/python3

# Copyright (C) 2017, Benjamin Drung 
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS 

Bug#570623: reprepro: please add multiple version management

[Johannes Amorosa]

On 29.03.2017 19:31, Benjamin Drung wrote:

Hi everyone,

I am happy to announce the feature complete version of reprepro 5.1.1
with multiple version management. Attached are all 58 patches. You can
also pull the 5.1.1-mutiple-versions branch from
https://github.com/profitbricks/reprepro
Feel free to report bugs on GitHub.

Bernhard, please review my patches and include the patches that you
like. Some patches are unrelated to the multiple versions feature (e.g.
patches 11 and 12). Some patches could already be included even when
you do not apply the final patch. Let me know if you want further
refactoring.

Release Notes
=

The multiple-versions patch set adds following features:

* Add shunit2 based tests (Closes: #857302)
* Support multiple versions. (Closes: #570623)
* Add listdistros command (Closes: #857303)
* Add the commands move, movesrc, movematched, movefilter
* Add Limit and Archive option

Behavior changes


The multiple-versions reprepro keeps all package versions in the
archive. Set "Limit: 1" to keep only one version per package in the
archive to restore the previous behavior.

Database layout changes
---

The database layout changes from the upstream 5.1.1 release to the
multiple versions patch set. The difference is as following:

5.1.1:

* packages.db maps "package name" to "control file" without duplicates
* no packagenames.db

5.1.1 + multiple versions:

* packages.db maps "package name|version" to "control file" without
duplicates
* packagenames.db maps "package name" to "package name|version"
allowing duplicates and duplicates sorted by dpkg --compare-versions
descending

The multiple-versions reprepro supports migrating from 5.1.1 to
5.1.1 + multiple versions. Warning: There is no way back (but could be
done with a simple Python script)!

Notes for users of 4.16.1 + multiple versions
-

The database layout of the multiple-versions branch changed between
the 4.17.1 based patch set and the 5.1.1 patch set. Attached is the
small Python script 'migrate-db-from-4.17-to-5.1' to migrate the
database to the new layout. You have to install python3-bsddb3 and run
the script in basedir. It should be idempontent.



@Benjamin Great thanks for doing this work. Looking forward to a release 
- it's a feature we're in need.


Greeting from Berlin to Berlin
Johannes

Bug#570623: Info received (Bug#570623: reprepro: please add multiple version management)

[Devel Chip]

ATTENTION: I have no idea of what I'm doing

fixing update/sync:

diff --git a/upgradelist.c b/upgradelist.c
index 272b46c..8ee0de2 100644
--- a/upgradelist.c
+++ b/upgradelist.c
@@ -126,7 +126,7 @@ static retvalue save_package_version(struct upgradelist
*upgrade, const char *pa
if (strcmp(packagename, upgrade->last->name) > 0) {
upgrade->last->next = package;
upgrade->last = package;
-   } else {
+   } else if (strcmp(packagename, upgrade->last->name) != 0) {
/* this should only happen if the underlying
 * database-method get changed, so just throwing
 * out here */


On 18 April 2016 at 08:42, Debian Bug Tracking System  wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Bernhard R. Link 
>
> If you wish to submit further information on this problem, please
> send it to 570...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 570623: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#570623: reprepro: please add multiple version management

[Devel Chip]

> Error while parsing 'asterisk-config|1:13.3.0-acos1+o0' as version: epoch in 
> version is not number

I don't think that '|' character is allowed in the names by design.

But I've encountered another unrelated problem when syncing.

The conf/updates file (package name is in the mirror.packages):

Name: upstream-update
Method: http://localhost:20080/
Components: main
FilterList: purge ../mirror.packages

The receiving repository has multiple versions of a package.

The following error occurs:

Calculating packages to get...
Package database is not sorted!!!
reprepro: upgradelist.c:134: save_package_version: Assertion `0' failed.

Bug#570623: reprepro: please add multiple version management

[David Kleuker]

we would really like to have this. any updates?

Bug#570623: reprepro: please add multiple version management

[Walter Doekes]

Cool. So, I tested this by installing:

  - https://alioth.debian.org/anonscm/git/mirrorer/mirrorer.git
(git repo)

  - branched off the (default) debian branch [2]

  - patched with Add-multiple-version-management.patch

https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=70;filename=Add-multiple-version-management.patch;att=15;bug=570623

  - fixed 3 conflicts in main.c, not sure what was conflicting, probably
leftover whitespace or something.

  - autoreconf -vi (see INSTALL for dependencies)
  - ./configure --prefix=/usr/local; make; make install
  - renamed the resultant binaries with -mver suffix so they don't
conflict with the rest of my setup


Initial observations:

  - I started a new multi-version repository and loaded up several
versions of a package: it works.
  - Downgrading/upgrading a single package from that repository
works.

  - Warnings when including a new package:


debian-mver# reprepro-mver -C acos include wheezy 
/srv/junk/asterisk*13.3.*changes
Error while parsing 'asterisk-config|1:13.3.0-acos1+o0' as version: epoch in 
version is not number
Parse errors processing versions.
Error while parsing 'asterisk-dbg|1:13.3.0-acos1+o0' as version: epoch in 
version is not number
Parse errors processing versions.

...

It complained about the epoch in version not being a number. I
assume someone takes asterisk-config|1 to be an epoch, instead
of just 1. (See below/attachment for a fix.)

  - When including two packages with the same minor/micro version,
things were less okay:


debian-mver# reprepro-mver -C acos include wheezy 
/srv/junk/old/asterisk_13.2.0*acos2*changes
Error while parsing 'asterisk-config|1:13.2.0-acos2+o0+2up' as version: epoch 
in version is not number
Parse errors processing versions.

...

Internal error of the underlying BerkeleyDB database:
Within references.db subtable references at put: DB_KEYEXIST: Key/data pair 
already exists
Warning: database 'wheezy|acos|amd64' was modified but no index file was 
exported.
Changes will only be visible after the next 'export'!
There have been errors!


   But a dump [1] of the references file revealed no immediate problem:


debian-mver# diff -pu (cat -A references.db.2) (cat -A references.db.3)
--- /dev/fd/63  2015-04-07 11:45:35.900044000 +0200
+++ /dev/fd/62  2015-04-07 11:45:35.900044000 +0200
@@ -8,38 +8,72 @@ db_pagesize=4096$
 HEADER=END$
   pool/acos/a/asterisk/asterisk-config_13.2.0-acos1+o0+2up_all.deb^@$
   wheezy|acos|amd64^@$
+  pool/acos/a/asterisk/asterisk-config_13.2.0-acos2+o0+2up_all.deb^@$
+  wheezy|acos|amd64^@$

...

  I added a few debug prints, and I got this:

...

Skipping inclusion of 'asterisk-modules' '1:13.2.0-acos2+o0+2up' in 
'wheezy|acos|amd64', as this version already exists.
Skipping inclusion of 'asterisk' '1:13.2.0-acos2+o0+2up' in 
'wheezy|acos|amd64', as this version already exists.



db: 'pool/acos/a/asterisk/asterisk_13.2.0-acos2+o0+2up.dsc' adding to 
references.db(references).
Internal error of the underlying BerkeleyDB database:
Within references.db subtable references at put: DB_KEYEXIST: Key/data pair 
already exists
db: 'pool/acos/a/asterisk/asterisk_13.2.0.orig.tar.gz' adding to 
references.db(references).
Internal error of the underlying BerkeleyDB database:
Within references.db subtable references at put: DB_KEYEXIST: Key/data pair 
already exists
db: 'pool/acos/a/asterisk/asterisk_13.2.0-acos2+o0+2up.debian.tar.gz' adding to 
references.db(references).
Internal error of the underlying BerkeleyDB database:
Within references.db subtable references at put: DB_KEYEXIST: Key/data pair 
already exists
There have been errors!


  Those errors only popped up when uploading the 2nd (acos2) version.
  For the first (acos1), I just get the Skipping notices like
  expected (when calling it a second/third time).

  - Removing a package worked, unless we have multiple versions:


debian-mver# reprepro-mver -C acos remove wheezy 
libpjproject-dev=2.3.0.0.ast20150218-acos1


  OK

  - Removing a package did not work when we have multiple versions:


debian-mver# reprepro-mver  -C acos list wheezy | head -n2
wheezy|acos|amd64: asterisk 1:13.3.0-acos1+o0
wheezy|acos|amd64: asterisk 1:13.2.0-acos2+o0+2up

...

debian-mver# reprepro-mver -C acos remove wheezy asterisk=1:13.2.0-acos2+o0+2up
removing 'asterisk=1:13.2.0-acos2+o0+2up' from 'wheezy|acos|amd64'...
Error while parsing 'asterisk|1:13.2.0-acos2+o0+2up' as version: epoch in 
version is not number
Parse errors processing versions.
Error while parsing 'asterisk|1:13.2.0-acos2+o0+2up' as version: epoch in 
version is not number
Parse errors processing versions.
/srv/reprepro/debian-mver/db/packages.db/wheezy|acos|amd64: DB_SECONDARY_BAD: 
Secondary index inconsistent with primary
Internal error of the underlying BerkeleyDB database:
Within packages.db subtable wheezy|acos|amd64 at del: DB_SECONDARY_BAD: 
Secondary index inconsistent with primary
There have been errors!


  - However, when adding 

Bug#570623: reprepro: please add multiple version management

[Johannes Amorosa | Celluloid VFX]

Exactly what I need.
Looking forward to have this patch in the package repository.
Can I help to implement this?

Joe


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Michael Stucki]

What is the status of this project? It looks complete so what is needed to
have this merged?
Let me know how I can help!

Bug#570623: reprepro: please add multiple version management

[Bernhard R. Link]

* Benjamin Drung benjamin.dr...@profitbricks.com [140612 17:30]:
 the logging and tracking was not working in all cases when adding
 packages with the include command. The fix is in the attached 0003
 patch. The include and processincoming commands do work now (except when
 these commands want to remove a package, which is still on my todo
 list).

What version of reprepro is that patch relative to? I'm a bit at loss
at packagedata.c.


Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Am Freitag, den 23.05.2014, 23:39 +0200 schrieb Bernhard R. Link:
 * Benjamin Drung benjamin.dr...@profitbricks.com [140521 16:48]:
  I got distracted by different tasks, but now I have time to work on
  reprepro again.
  
  Am Dienstag, den 04.02.2014, 23:23 +0100 schrieb Bernhard R. Link:
   * Benjamin Drung benjamin.dr...@profitbricks.com [140203 13:15]:
Okay. Attached the patch for my prototype. Be aware: It's just a
prototype that is just able to run the commands that I wanted to test,
but isn't near to be ready for mainlining. The prototype implements case
2 just because that was my initial idea, but now I tend to think that
case 1 might be easier/cleaner.
  
   Thanks. I'll take a look this weekend.
 
  Any feedback so far?
 
 It's too long ago for me to remember. AFAIR it mostly was that libdb
 trick that is quite hard to understand.

My current approach is to use the secondary DB again (case 2). The
primary DB stores packagename+version (e.g. hello|2.5-1) and does not
allow duplicates. The secondary DB stores just the packagename (e.g.
hello) and does allow duplicates. The duplicates are sorted by their
version.

The function get_package_name is used to derives the secondary key from
the primary key by extracting the packagename (e.g. hello|2.5-1 -
hello).

This approach has the advantage that these operations are easy to
implement/cost efficient:

1) get the latest package version (first entry in the secondary DB for a
given package name)
2) get a specific package version (entry in the primary DB for a given
packagename+version combination)

For example adding a new package would do this:
Get the latest package version for the given package name (1). If the
result is NULL or the returned package version is older than the new
package, add the new package. If the version is the same, reject the new
package. If the version is newer than the new package, check if the
package version is already present in the archive (2) and reject it in
this case. Otherwise add the new package if downgrades are allowed.

 It sounds quite slow either way. Perhaps the way to go is instead
 changing the data format, like having the version first (perhaps even 
 in
 preparsed format to speed things up).
   
Good idea, but is this function really time critical? It should be only
called when comparing duplicate keys (which shouldn't happen that often,
does it?).
   
   It might also happen when updating some value otherwise. (And if the
   version is in some meta-data first one also does not have to
   differentiate between binaries and sources that much). One could also
   take the opportunity of a format change to allow for other possible
   future meta data (like the first added timestamp).
  
  How flexible should the new data structure be? What meta data besides
  the timestamp could be relevant?
 
 It would be nice if it allowed other fields to be added later without
 breaking the format again. Like some (field-length-content)* format.

Fields to store (for the beginning):
1) package version string
2) control chunk string
3) added timestamp

Here are different, but similar on-disk format proposals:

First variant
=

Physical order of the data
--

field 1
field 2
...
field n
sizeof(field n) [stored as 32-bit unsigned int]
...
sizeof(field 2) [stored as 32-bit unsigned int]
sizeof(field 1) [stored as 32-bit unsigned int]
number of field [stored as 8-bit (or 16-bit?) unsigned int]

In our case this would be
-

[variable] package version string + '\0'
[variable] control chunk string + '\0'
[8 bytes] timestamp (which format? 64-bit Unix timestamp?)
[4 bytes] sizeof(timestamp) = 8 (in case of 64-bit timestamp)
[4 bytes] strlen(control chunk) + 1
[4 bytes] strlen(package version) + 1
[1 byte] 3

Access to the individual entries for a given void *data and size_t len:
size_t end = (size_t)data + len;

char *version = (char*)data;
size_t version_len = *(uint32_t)(end - sizeof(uint8_t) - sizeof(uint32_t));
fail if *(uint8_t)(end - sizeof(uint8_t))  1

char chunk = (char*)((size_t)data + version_len);
size_t chunk_len = *(uint32_t)(end - sizeof(uint8_t) - 2 * sizeof(uint32_t));
fail if *(uint8_t)(end - sizeof(uint8_t))  2

time_t timestamp = *(int64_t)((size_t)data + version_len + chunk_len);
fail if *(uint8_t)(end - sizeof(uint8_t))  3

Additional checks:
size_t timestamp_len = *(uint32_t)(end - sizeof(uint8_t) - 3 * 
sizeof(uint32_t));
timestamp_len == sizeof(int64_t)
len == version_len + chunk_len + timestamp_len + sizeof(uint8_t) + 3 * 
sizeof(uint32_t)

Second variant
==

The second variant is similar to the first, but only the size of fields
are stored that have a variable length. In our case, we would store the
length of the version and control chunk, but not the length of the
timestamp.

third variant
=

Instead of storing the length of the field, the offset is stored:

Physical order of 

Bug#570623: reprepro: please add multiple version management

[Bernhard R. Link]

* Benjamin Drung benjamin.dr...@profitbricks.com [140521 16:48]:
 I got distracted by different tasks, but now I have time to work on
 reprepro again.
 
 Am Dienstag, den 04.02.2014, 23:23 +0100 schrieb Bernhard R. Link:
  * Benjamin Drung benjamin.dr...@profitbricks.com [140203 13:15]:
   Okay. Attached the patch for my prototype. Be aware: It's just a
   prototype that is just able to run the commands that I wanted to test,
   but isn't near to be ready for mainlining. The prototype implements case
   2 just because that was my initial idea, but now I tend to think that
   case 1 might be easier/cleaner.
 
  Thanks. I'll take a look this weekend.

 Any feedback so far?

It's too long ago for me to remember. AFAIR it mostly was that libdb
trick that is quite hard to understand.

It sounds quite slow either way. Perhaps the way to go is instead
changing the data format, like having the version first (perhaps even in
preparsed format to speed things up).
  
   Good idea, but is this function really time critical? It should be only
   called when comparing duplicate keys (which shouldn't happen that often,
   does it?).
  
  It might also happen when updating some value otherwise. (And if the
  version is in some meta-data first one also does not have to
  differentiate between binaries and sources that much). One could also
  take the opportunity of a format change to allow for other possible
  future meta data (like the first added timestamp).
 
 How flexible should the new data structure be? What meta data besides
 the timestamp could be relevant?

It would be nice if it allowed other fields to be added later without
breaking the format again. Like some (field-length-content)* format.

   How do you want to preparse the version?
  
  if versions are compared they are split into epoch version and revision
  and version and revision are gain split into sequences of numbers and
  not-numbers. Dpkg for example first parsed all the functions and later
  only compares the already split part. if easily possible it could make
  sense to store it in a format like that (but then parsing a on-disk
  format of the split data might be just as time-consuming as just looking
  at the real data).
 
 The version and revision can have a nearly unlimited amount of
 concatenated numbers and not-numbers. You could store the parts as list
 with type information. I doubt that a different on-disk format could
 increase the speed. We could split the full version into epoch, version,
 and revision and store them separately, but parsing these parts will be
 more time consuming. My feeling is that we should stick with the full
 version as string.

Yes, might not make much sense if one has to store the preparsed format.

 While working on reprepro, I found a typo. A patch for that is attached.

applied.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Hi,

I got distracted by different tasks, but now I have time to work on
reprepro again.

Am Dienstag, den 04.02.2014, 23:23 +0100 schrieb Bernhard R. Link:
 * Benjamin Drung benjamin.dr...@profitbricks.com [140203 13:15]:
  Okay. Attached the patch for my prototype. Be aware: It's just a
  prototype that is just able to run the commands that I wanted to test,
  but isn't near to be ready for mainlining. The prototype implements case
  2 just because that was my initial idea, but now I tend to think that
  case 1 might be easier/cleaner.
 
 Thanks. I'll take a look this weekend.

Any feedback so far?

   It sounds quite slow either way. Perhaps the way to go is instead
   changing the data format, like having the version first (perhaps even in
   preparsed format to speed things up).
 
  Good idea, but is this function really time critical? It should be only
  called when comparing duplicate keys (which shouldn't happen that often,
  does it?).
 
 It might also happen when updating some value otherwise. (And if the
 version is in some meta-data first one also does not have to
 differentiate between binaries and sources that much). One could also
 take the opportunity of a format change to allow for other possible
 future meta data (like the first added timestamp).

How flexible should the new data structure be? What meta data besides
the timestamp could be relevant?

  How do you want to preparse the version?
 
 if versions are compared they are split into epoch version and revision
 and version and revision are gain split into sequences of numbers and
 not-numbers. Dpkg for example first parsed all the functions and later
 only compares the already split part. if easily possible it could make
 sense to store it in a format like that (but then parsing a on-disk
 format of the split data might be just as time-consuming as just looking
 at the real data).

The version and revision can have a nearly unlimited amount of
concatenated numbers and not-numbers. You could store the parts as list
with type information. I doubt that a different on-disk format could
increase the speed. We could split the full version into epoch, version,
and revision and store them separately, but parsing these parts will be
more time consuming. My feeling is that we should stick with the full
version as string.

  How would the data format change? Currently the database value contains
  just the control junk. We could put the pair (version, control) as value
  into the database. How should the pair separated? Maybe with a null
  character?
 
 something like that.
 
  Then we could just use the pointer to the value as version
  string (the null character from the pair separation would also be used
  to terminate the string).
 
 Yes. That would be the store verbatim and non-preparsed variant.
 Alternatively one could first store a length of the string, so one can
 even faster jump to the control part.

What do you prefer? My current implementation just concatenates the
version string (including it's null character) and the control chunk. I
could expand the tuple to a tripple and add the timestamp (in which
format?) as third parameter.

While working on reprepro, I found a typo. A patch for that is attached.

-- 
Benjamin Drung
System Developer

ProfitBricks GmbH - The IaaS-Company
Greifswalder Str. 207
D - 10405 Berlin

Mail: benjamin.dr...@profitbricks.com
Fax:  +49 30 577 008 598
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
From 02a9440ac87532adfdf63a4e510e783f310708a9 Mon Sep 17 00:00:00 2001
From: Benjamin Drung benjamin.dr...@profitbricks.com
Date: Tue, 20 May 2014 15:10:12 +0200
Subject: [PATCH 1/1] Fix typo connot - cannot.

---
 database.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/database.c b/database.c
index 83eb652..377ede3 100644
--- a/database.c
+++ b/database.c
@@ -942,7 +942,7 @@ static const char databaseerror[] = Internal error of the underlying BerkeleyDB
 /
  * Stuff to handle data in tables   *
  
- There is nothing that connot be solved by another layer of indirection, except
+ There is nothing that cannot be solved by another layer of indirection, except
  too many levels of indirection. (Source forgotten) */
 
 struct table {
-- 
1.9.1

Bug#570623: reprepro: please add multiple version management

[Bernhard R. Link]

* Benjamin Drung benjamin.dr...@profitbricks.com [140203 13:15]:
 Okay. Attached the patch for my prototype. Be aware: It's just a
 prototype that is just able to run the commands that I wanted to test,
 but isn't near to be ready for mainlining. The prototype implements case
 2 just because that was my initial idea, but now I tend to think that
 case 1 might be easier/cleaner.

Thanks. I'll take a look this weekend.

  It sounds quite slow either way. Perhaps the way to go is instead
  changing the data format, like having the version first (perhaps even in
  preparsed format to speed things up).

 Good idea, but is this function really time critical? It should be only
 called when comparing duplicate keys (which shouldn't happen that often,
 does it?).

It might also happen when updating some value otherwise. (And if the
version is in some meta-data first one also does not have to
differentiate between binaries and sources that much). One could also
take the opportunity of a format change to allow for other possible
future meta data (like the first added timestamp).

 How do you want to preparse the version?

if versions are compared they are split into epoch version and revision
and version and revision are gain split into sequences of numbers and
not-numbers. Dpkg for example first parsed all the functions and later
only compares the already split part. if easily possible it could make
sense to store it in a format like that (but then parsing a on-disk
format of the split data might be just as time-consuming as just looking
at the real data).

 How would the data format change? Currently the database value contains
 just the control junk. We could put the pair (version, control) as value
 into the database. How should the pair separated? Maybe with a null
 character?

something like that.

 Then we could just use the pointer to the value as version
 string (the null character from the pair separation would also be used
 to terminate the string).

Yes. That would be the store verbatim and non-preparsed variant.
Alternatively one could first store a length of the string, so one can
even faster jump to the control part.


Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

On So, 2014-02-02 at 14:06 +0100, Bernhard R. Link wrote:
 * Benjamin Drung benjamin.dr...@profitbricks.com [140108 15:51]:
 
 First sorry for my late reply. I must have totally missed your mail.

No problem. I have been kept busy with other projects. ;)

  The first step is to agree on the database layout change. I came up with
  two alternatives:
 
  1) Allow duplicate entries in packages.db and sort duplicate entries by
  their Debian version. They can be sorted a) upwards or b) downwards.
  Depending on the request, we will either search for all versions of a
  package, one specific version of the package, or for the latest version
  of a package.
 
  2) Rename the key of packages.db to also contain the version of the
  package, e.g. sl|3.03-17 or hello_2.8-4 (which delimiter should we
  use?). This would allow us to check directly for a specific version of a
  package. We need to add a secondary table that allows us to access the
  database as described in 1) through the secondary table. This secondary
  table will allow duplicate entries and the values of the secondary table
  point to the key in packages.db. Depending on the task, we either query
  the first or secondary table. The secondary table will be kept in sync
  by BerkeleyDB.
 
  In the first case, we need to add a function to iterate over the
  duplicate packages to find a specific version. In the second case, we
  need to create the secondary table and transform the database.
 
  Which layout do you prefer?
 
 I think that layout is better that better fits the code. Not yet having
 looked at the code, I cannot say. I guess 1 might be simpler. In the
 case of 2 I think | is fine, as it is already used elsewhere (though
 I guess one should make sure reprepro does not allow | in package
 names).

Okay. Attached the patch for my prototype. Be aware: It's just a
prototype that is just able to run the commands that I wanted to test,
but isn't near to be ready for mainlining. The prototype implements case
2 just because that was my initial idea, but now I tend to think that
case 1 might be easier/cleaner.

  Another issue is the sorting of the packages in the database. We need
  one function to sort all entries in the table. So we need one function
  to sort binary packages and source packages, but we have
  binaries_getversion() and source_getversion(). Here's the example code
  (without the error handling) of the sorting function:
  
  static int debianversioncompare(UNUSED(DB *db), const DBT *a, const DBT *b) 
  {
  char *a_version, *b_version;
  int versioncmp;
  
  binaries_getversion(a-data, a_version);
  binaries_getversion(b-data, b_version);
  dpkgversions_cmp(a_version, b_version, versioncmp);
  return versioncmp;
  }
  
  Do you have a suggestion how to improve this function?
 
 It sounds quite slow either way. Perhaps the way to go is instead
 changing the data format, like having the version first (perhaps even in
 preparsed format to speed things up).

Good idea, but is this function really time critical? It should be only
called when comparing duplicate keys (which shouldn't happen that often,
does it?). How do you want to preparse the version?

How would the data format change? Currently the database value contains
just the control junk. We could put the pair (version, control) as value
into the database. How should the pair separated? Maybe with a null
character? Then we could just use the pointer to the value as version
string (the null character from the pair separation would also be used
to terminate the string).

-- 
Benjamin Drung
System Developer

ProfitBricks GmbH - The IaaS-Company
Greifswalder Str. 207
D - 10405 Berlin

Mail: benjamin.dr...@profitbricks.com
Fax:  +49 30 577 008 598
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
diff --git a/binaries.c b/binaries.c
index e66803d..74b4224 100644
--- a/binaries.c
+++ b/binaries.c
@@ -216,6 +216,20 @@ static inline retvalue calcnewcontrol(const char *chunk, const char *packagename
 	return RET_OK;
 }
 
+retvalue binaries_getpackage(const char *control, char **package) {
+	retvalue r;
+
+	r = chunk_getvalue(control, Package, package);
+	if (RET_WAS_ERROR(r))
+		return r;
+	if (r == RET_NOTHING) {
+		fprintf(stderr, Missing 'Package' field in chunk:'%s'\n,
+control);
+		return RET_ERROR;
+	}
+	return r;
+}
+
 retvalue binaries_getversion(const char *control, char **version) {
 	retvalue r;
 
diff --git a/binaries.h b/binaries.h
index ff1a9e6..a44bfe1 100644
--- a/binaries.h
+++ b/binaries.h
@@ -14,6 +14,7 @@
 
 
 /* Functions for the target.h-stuff: */
+get_package binaries_getpackage;
 get_version binaries_getversion;
 get_installdata binaries_getinstalldata;
 get_architecture binaries_getarchitecture;
diff --git a/chunks.c b/chunks.c
index ca1fd9e..82ae15a 100644
--- a/chunks.c
+++ b/chunks.c
@@ -120,6 +120,35 @@ retvalue 

Bug#570623: reprepro: please add multiple version management

[Bernhard R. Link]

* Benjamin Drung benjamin.dr...@profitbricks.com [140108 15:51]:

First sorry for my late reply. I must have totally missed your mail.

 The first step is to agree on the database layout change. I came up with
 two alternatives:

 1) Allow duplicate entries in packages.db and sort duplicate entries by
 their Debian version. They can be sorted a) upwards or b) downwards.
 Depending on the request, we will either search for all versions of a
 package, one specific version of the package, or for the latest version
 of a package.

 2) Rename the key of packages.db to also contain the version of the
 package, e.g. sl|3.03-17 or hello_2.8-4 (which delimiter should we
 use?). This would allow us to check directly for a specific version of a
 package. We need to add a secondary table that allows us to access the
 database as described in 1) through the secondary table. This secondary
 table will allow duplicate entries and the values of the secondary table
 point to the key in packages.db. Depending on the task, we either query
 the first or secondary table. The secondary table will be kept in sync
 by BerkeleyDB.

 In the first case, we need to add a function to iterate over the
 duplicate packages to find a specific version. In the second case, we
 need to create the secondary table and transform the database.

 Which layout do you prefer?

I think that layout is better that better fits the code. Not yet having
looked at the code, I cannot say. I guess 1 might be simpler. In the
case of 2 I think | is fine, as it is already used elsewhere (though
I guess one should make sure reprepro does not allow | in package
names).

 Another issue is the sorting of the packages in the database. We need
 one function to sort all entries in the table. So we need one function
 to sort binary packages and source packages, but we have
 binaries_getversion() and source_getversion(). Here's the example code
 (without the error handling) of the sorting function:
 
 static int debianversioncompare(UNUSED(DB *db), const DBT *a, const DBT *b) {
 char *a_version, *b_version;
 int versioncmp;
 
 binaries_getversion(a-data, a_version);
 binaries_getversion(b-data, b_version);
 dpkgversions_cmp(a_version, b_version, versioncmp);
 return versioncmp;
 }
 
 Do you have a suggestion how to improve this function?

It sounds quite slow either way. Perhaps the way to go is instead
changing the data format, like having the version first (perhaps even in
preparsed format to speed things up).


Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Benjamin Drung]

Hi,

I am in the process of making reprepro support multiple packages per
distribution/architecture/component/type quadruple. This requires bigger
changes in the database layout and all internal logic. I have a working
prototype (for including binary packages). I plan to extent this patch
to get it in an upstream acceptable state. I like to have guidance how
to implement some things before implementing them to avoid a result that
will be rejected.

The first step is to agree on the database layout change. I came up with
two alternatives:

1) Allow duplicate entries in packages.db and sort duplicate entries by
their Debian version. They can be sorted a) upwards or b) downwards.
Depending on the request, we will either search for all versions of a
package, one specific version of the package, or for the latest version
of a package.

2) Rename the key of packages.db to also contain the version of the
package, e.g. sl|3.03-17 or hello_2.8-4 (which delimiter should we
use?). This would allow us to check directly for a specific version of a
package. We need to add a secondary table that allows us to access the
database as described in 1) through the secondary table. This secondary
table will allow duplicate entries and the values of the secondary table
point to the key in packages.db. Depending on the task, we either query
the first or secondary table. The secondary table will be kept in sync
by BerkeleyDB.

In the first case, we need to add a function to iterate over the
duplicate packages to find a specific version. In the second case, we
need to create the secondary table and transform the database.

Which layout do you prefer?

Another issue is the sorting of the packages in the database. We need
one function to sort all entries in the table. So we need one function
to sort binary packages and source packages, but we have
binaries_getversion() and source_getversion(). Here's the example code
(without the error handling) of the sorting function:

static int debianversioncompare(UNUSED(DB *db), const DBT *a, const DBT *b) {
char *a_version, *b_version;
int versioncmp;

binaries_getversion(a-data, a_version);
binaries_getversion(b-data, b_version);
dpkgversions_cmp(a_version, b_version, versioncmp);
return versioncmp;
}

Do you have a suggestion how to improve this function?

Cheers,
Benjamin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Jean-Christophe Dubacq]

Package: reprepro
Version: 4.0.2-1
Severity: wishlist

Currently, indices built by reprepro only show the latest version of
a package. I really would like to use reprepro to have an archive
with multiple versions of a package accessible (eg for rollback).

currently I do something like that after each addition to the
repository:
cd debian
apt-ftparchive generate conf/storage.conf
apt-ftparchive -c conf/releasestorage.conf release dists/storage  
dists/storage/Release
if [ -f dists/storage/Release.gpg ]; then
  rm dists/storage/Release.gpg
fi
gpg --output dists/storage/Release.gpg -ba dists/storage/Release
cd ..

But it does not take only what is tracked in the 'storage' dist,
it takes everything in the pool.

It would work much better at reprepro level.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'stable'), (50, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages reprepro depends on:
ii  libarchive1 2.6.2-1  Single library to read/write tar, 
ii  libbz2-1.0  1.0.5-4  high-quality block-sorting file co
ii  libc6   2.10.2-6 Embedded GNU C Library: Shared lib
ii  libdb4.84.8.26-1 Berkeley v4.8 Database Libraries [
ii  libgpg-error0   1.6-1library for common error values an
ii  libgpgme11  1.2.0-1.2GPGME - GnuPG Made Easy
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages reprepro recommends:
ii  apt   0.7.25.3   Advanced front-end for dpkg

Versions of packages reprepro suggests:
ii  gnupg-agent   2.0.14-1   GNU privacy guard - password agent
pn  inoticoming   none (no description available)
ii  lzma  4.43-14Compression method of 7z format in
ii  xz-utils  4.999.9beta+20100212-1 XZ-format compression utilities

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570623: reprepro: please add multiple version management

[Bernhard R. Link]

* Jean-Christophe Dubacq jcduba...@free.fr [100220 11:14]:
 Currently, indices built by reprepro only show the latest version of
 a package. I really would like to use reprepro to have an archive
 with multiple versions of a package accessible (eg for rollback).

Sorry, that is not coming soon. Having one version of a package per
distribution/architecture/component/type quadruple is heavily built into
the database layout and all the internal logic.

If you want different versions of the same package in the same
architecture with reprepro, you need to either store them in different
distributions, or you can create snapshots of distributions.
(You can also enable tracking with the options to not remove old
packages, but that will only keep the files in the pool and not in any
apt-getable index).

Hochachtungsvoll,
Bernhard R. Link



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org