Package: reprepro
Version: 3.6.0-1
Severity: wishlist
--- Please enter the report below this line. ---
In this use case, I uploaded a package with a default debhelper
template control file as shown:
Source: myexample-dbdump
Section: unknown
Priority: extra
Maintainer: Ryan Hass <[EMAIL PROTECTED]>
Build-Depends: cdbs, debhelper (>= 5)
Standards-Version: 3.7.2
Package: myexample-dbdump-package
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>
We will call this bad version with the section defined as 'unknown',
version 1.0.1-1. Version 1.0.1-1 was then pulled from the development
dist, into the alpha and beta dists. (dev/main, alpha/main, and
beta/main.) A second version (1.0.2.-1), also with the bad section
defined was uploaded into dev/main and alpha/main. Upon reviewing the
package, I realized my error and updated the control file so that the
information was correct and in doing so changed the section from
'unknown' (which I configured to default into the section 'main') to
'extra' -- creating a third version 1.0.2-2. The result when version
1.0.2-2 was uploaded and a 'processincoming' performed on dev, and
pulled into the alpha dist. The old versions (1.0.1-1 and 1.0.2-1)
remained in the section 'main' , while the new version (1.0.2-1)
populated in the section 'extra.' While normally I would consider this
to be a nifty feature, an inconsistency arises in the following unique
situation.
When an attempt to copy (downgrade) the package version 1.0.1-1from
beta/main to back into alpha/main is performed, the version 1.0.2-2 will
be removed from the section 'extra' -- however, the 1.0.2-1 version in
alpha/main remains. Thus, 1.0.1-1 is trumped by a version which I did
not intend to keep in the repository. While I see this behavior being
useful with a new OS release version, in this particular instance where
the OS release is the same, it is not the desired behavior.
The desired or perhaps expected behavior when downgrading a package for
the same OS release version, is to remove any version which is greater
than the version to which reprepro is downgrading.
I know this is a very confusing use case... it took me half the day just
to figure out how to put it all into writing to make this even somewhat
coherent. Nevertheless, please let me know where of any points of
confusion so I can attempt to clarify. To me, this seems like one of
those odd cases where it is not quite a bug, and not quite an intended
design feature -- this said, I have set the case to the priority
"wishlist." In any case, I was able to just remove the offending package
with removefilter without an incident.
Thanks.
-Ryan H.
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.24-19-generic
Debian Release: lenny/sid
500 hardy-updates CENSORED
500 hardy-seereason deb.seereason.com
500 hardy-security CENSORED
500 hardy-backports CENSORED
500 hardy CENSORED
--- Package information. ---
Depends (Version) | Installed
=======================================-+-======================
libarchive1 (>= 2.2.4) | 2.2.4-1ubuntu1
libbz2-1.0 | 1.0.4-2ubuntu4
libc6 (>= 2.4) | 2.7-10ubuntu4
libdb4.3 (>= 4.3.28-1) | 4.3.29-11ubuntu1
libgpg-error0 (>= 1.4) | 1.4-2ubuntu7
libgpgme11 (>= 1.0.1) | 1.1.5-2ubuntu1
zlib1g (>= 1:1.2.3.3.dfsg-1) | 1:1.2.3.3.dfsg-7ubuntu1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
