Hi, I wonder if I can get some advice from the list? I want to run a little Debian repository -- but I have a requirement which seems to be missing from the software tried so far. I want the repository to maintain multiple versions of the same package. ie. So I could do this: dput my-package_1.00-1_all.deb dput my-package_1.11-1_all.deb dput my-package_2.00-1_all.deb And then on a machine using my repo, be able to say something like: aptitude install my-package (> 1.10 & < 1.99) while on another machine, say: aptitude install my-package (>= 2.00) So far, repo management software I've seen will purge the older version out when you upload a new one. Any thoughts? Thanks, Toby
On 28/06/2012, at 17:49, Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
Hi, I wonder if I can get some advice from the list?
I want to run a little Debian repository -- but I have a requirement which seems to be missing from the software tried so far.
I want the repository to maintain multiple versions of the same package.
ie. So I could do this:
dput my-package_1.00-1_all.deb dput my-package_1.11-1_all.deb dput my-package_2.00-1_all.deb
And then on a machine using my repo, be able to say something like:
aptitude install my-package (> 1.10 & < 1.99) while on another machine, say: aptitude install my-package (>= 2.00)
So far, repo management software I've seen will purge the older version out when you upload a new one.
Any thoughts?
Thanks, Toby
Reprepro handles this really well. Check out its man page under the Override Files section and look for unused_files setting and the options for it. Edward
On 28/06/12 18:28, Edward Savage wrote:
On 28/06/2012, at 17:49, Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
Hi, I wonder if I can get some advice from the list?
I want to run a little Debian repository -- but I have a requirement which seems to be missing from the software tried so far.
I want the repository to maintain multiple versions of the same package.
ie. So I could do this:
dput my-package_1.00-1_all.deb dput my-package_1.11-1_all.deb dput my-package_2.00-1_all.deb
And then on a machine using my repo, be able to say something like:
aptitude install my-package (> 1.10 & < 1.99) while on another machine, say: aptitude install my-package (>= 2.00)
So far, repo management software I've seen will purge the older version out when you upload a new one.
Any thoughts?
Thanks, Toby
Reprepro handles this really well. Check out its man page under the Override Files section and look for unused_files setting and the options for it.
Hi Edward, reprepro is actually the main one I've been trying to use. If I add version 1 of a package, and then version 2, it deletes version 1, as per: # reprepro includedeb squeeze /home/tobyc/testpkg_2_amd64.deb /home/tobyc/testpkg_2_amd64.deb: component guessed as 'main' Exporting indices... Deleting files no longer referenced... deleting and forgetting pool/main/t/testpkg/testpkg_1_amd64.deb I've had a look at the Override Files man page section, and I really can't figure out how to use the "unused_files" with it. The man page describes that as: Permit A list of options to allow things otherwise causing errors: unused_files Do not stop with error if there are files listed in the .changes file if it lists files not belonging to any package in it. Cleanup options A list of options to cause more files in the incoming directory to be deleted: unused_files If there is unused_files in Permit then also delete those files when the package is deleted after successful processing. Could you suggest the actual option that I should be applying here? Thanks, Toby
Toby Corkindale wrote:
So far, repo management software I've seen will purge the older version out when you upload a new one.
echo >>Release NotAutomatic: yes # Workaround #272557. This will prevent all upgrades from that repo unless a human explicitly requests them. e.g. "apt-get dist-upgrade" will skip them. This flag is what debian/experimental uses. See also reprorepo, or http://cyber.com.au/~twb/snarf/apt-ftparchive for a cheapass alternative.
I want the repository to maintain multiple versions of the same package.
Either of the above should handle that fine.
And then on a machine using my repo, be able to say something like:
aptitude install my-package (> 1.10 & < 1.99) while on another machine, say: aptitude install my-package (>= 2.00)
You can't have that. Of the top of my head, you could: apt-get install foo=1.2.0 aptitude hold foo or pinning, ref. apt_preferences(5). Or create a stub package that has something like Conflicts: foo (>= 2~) or Breaks same, then install that on the one you want to keep at the old version. Or finally, if the two hosts are different suites, create foo 1.x and foo 2.x packages for the different suites in the first place. My wrapper script won't handle that, but any heavyweight one (i.e. one that *has* a pool/) should handle it just fine.
On 29/06/12 11:50, Trent W. Buck wrote:
Toby Corkindale wrote:
So far, repo management software I've seen will purge the older version out when you upload a new one.
echo >>Release NotAutomatic: yes # Workaround #272557.
This will prevent all upgrades from that repo unless a human explicitly requests them. e.g. "apt-get dist-upgrade" will skip them. This flag is what debian/experimental uses.
Nonono, I mean the repository management software deletes the package from the repository. I'm OK with the pinning and stuff on the client side.
See also reprorepo, or http://cyber.com.au/~twb/snarf/apt-ftparchive for a cheapass alternative.
I want the repository to maintain multiple versions of the same package.
Either of the above should handle that fine.
Both Edward and yourself have said that, but I can't figure out how to configure it as such -- I can't seem to work out how though -- reprepro deletes stuff out of the database once a new version comes in, and I am really struggling to find an option that prevents that. (It's not good enough to keep the .deb file in a directory -- it needs to be in the Packages.gz file as well or clients won't know about it) I don't suppose you have a config handy from a repo that's already configured to do this that you can paste in here? cheers, Toby
Toby Corkindale wrote:
On 29/06/12 11:50, Trent W. Buck wrote:
Toby Corkindale wrote:
So far, repo management software I've seen will purge the older version out when you upload a new one.
echo >>Release NotAutomatic: yes # Workaround #272557.
This will prevent all upgrades from that repo unless a human explicitly requests them. e.g. "apt-get dist-upgrade" will skip them. This flag is what debian/experimental uses.
Nonono, I mean the repository management software deletes the package from the repository. I'm OK with the pinning and stuff on the client side.
See also reprorepo, or http://cyber.com.au/~twb/snarf/apt-ftparchive for a cheapass alternative.
I want the repository to maintain multiple versions of the same package.
Either of the above should handle that fine.
Both Edward and yourself have said that, but I can't figure out how to configure it as such -- I can't seem to work out how though -- reprepro deletes stuff out of the database once a new version comes in, and I am really struggling to find an option that prevents that.
Sorry, I can't help there; ICBF learning reprepro (I can't even spell it reliably!) which is why I have my cheaparse script. As you can see, it doesn't do anything to the debs, it just creates the metadata files.
(It's not good enough to keep the .deb file in a directory -- it needs to be in the Packages.gz file as well or clients won't know about it)
That's what the script I linked to does.
I don't suppose you have a config handy from a repo that's already configured to do this that you can paste in here?
That's what the script I linked to creates. PS: I would still recommend reprorepo over my own thing, because it deals with multiple suites and so on, rather than a single flat dir. Also it's supported by Debian and stuff :P
On 30/06/12 01:42, Trent W. Buck wrote:
Toby Corkindale wrote:
On 29/06/12 11:50, Trent W. Buck wrote:
Toby Corkindale wrote:
So far, repo management software I've seen will purge the older version out when you upload a new one.
echo >>Release NotAutomatic: yes # Workaround #272557.
This will prevent all upgrades from that repo unless a human explicitly requests them. e.g. "apt-get dist-upgrade" will skip them. This flag is what debian/experimental uses.
Nonono, I mean the repository management software deletes the package from the repository. I'm OK with the pinning and stuff on the client side.
See also reprorepo, or http://cyber.com.au/~twb/snarf/apt-ftparchive for a cheapass alternative.
I want the repository to maintain multiple versions of the same package.
Either of the above should handle that fine.
Both Edward and yourself have said that, but I can't figure out how to configure it as such -- I can't seem to work out how though -- reprepro deletes stuff out of the database once a new version comes in, and I am really struggling to find an option that prevents that.
Sorry, I can't help there; ICBF learning reprepro (I can't even spell it reliably!) which is why I have my cheaparse script. As you can see, it doesn't do anything to the debs, it just creates the metadata files.
(It's not good enough to keep the .deb file in a directory -- it needs to be in the Packages.gz file as well or clients won't know about it)
That's what the script I linked to does.
I don't suppose you have a config handy from a repo that's already configured to do this that you can paste in here?
That's what the script I linked to creates.
PS: I would still recommend reprorepo over my own thing, because it deals with multiple suites and so on, rather than a single flat dir. Also it's supported by Debian and stuff :P
Yeah, given that we want to support multiple distributions, and do like having things that are actually supported upstream, I'd like to stay with one of the official systems. You said before that Reprepro could do what I want, but then you said you CBF learning Reprepro to explain how to use it.. Could I just check, have you actually, definitely seen Reprepro support the feature I want? I'd hate to spend ages trying to learn to configure it, only to find out that you were mistaken. thanks, Toby
twb> Either of the above should handle that fine. toby> You said before that Reprepro could do what I want, but then you toby> said you CBF learning Reprepro to explain how to use it.. Could toby> I just check, have you actually, definitely seen Reprepro toby> support the feature I want? I'd hate to spend ages trying to toby> learn to configure it, only to find out that you were mistaken. To be clear: I do not have first-hand experience of it doing what you want. Note that I said "should" not "could" -- I merely have the strong impression that it should do what you want.
On Mon, Jul 2, 2012 at 11:03 AM, Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
On 30/06/12 01:42, Trent W. Buck wrote:
Toby Corkindale wrote:
On 29/06/12 11:50, Trent W. Buck wrote:
Toby Corkindale wrote:
So far, repo management software I've seen will purge the older version out when you upload a new one.
echo >>Release NotAutomatic: yes # Workaround #272557.
This will prevent all upgrades from that repo unless a human explicitly requests them. e.g. "apt-get dist-upgrade" will skip them. This flag is what debian/experimental uses.
Nonono, I mean the repository management software deletes the package from the repository. I'm OK with the pinning and stuff on the client side.
See also reprorepo, or http://cyber.com.au/~twb/snarf/apt-ftparchive for a cheapass alternative.
I want the repository to maintain multiple versions of the same package.
Either of the above should handle that fine.
Both Edward and yourself have said that, but I can't figure out how to configure it as such -- I can't seem to work out how though -- reprepro deletes stuff out of the database once a new version comes in, and I am really struggling to find an option that prevents that.
Sorry, I can't help there; ICBF learning reprepro (I can't even spell it reliably!) which is why I have my cheaparse script. As you can see, it doesn't do anything to the debs, it just creates the metadata files.
(It's not good enough to keep the .deb file in a directory -- it needs to be in the Packages.gz file as well or clients won't know about it)
That's what the script I linked to does.
I don't suppose you have a config handy from a repo that's already configured to do this that you can paste in here?
That's what the script I linked to creates.
PS: I would still recommend reprorepo over my own thing, because it deals with multiple suites and so on, rather than a single flat dir. Also it's supported by Debian and stuff :P
Yeah, given that we want to support multiple distributions, and do like having things that are actually supported upstream, I'd like to stay with one of the official systems.
You said before that Reprepro could do what I want, but then you said you CBF learning Reprepro to explain how to use it.. Could I just check, have you actually, definitely seen Reprepro support the feature I want? I'd hate to spend ages trying to learn to configure it, only to find out that you were mistaken.
thanks, Toby
On much deeper inspection it looks like it can't. I hadn't realised the multiples of packages in our repository was considered a bug (fixed by deleteunreferenced) so my apologies. You can have multiple source tracking however this does not exist for packages. http://anonscm.debian.org/gitweb/?p=mirrorer/reprepro.git;a=blob_plain;f=doc...
3.1) Can I have two versions of a package in the same distribution? ------------------------------------------------------------------- Sorry, this is not possible right now, as reprepro heavily optimizes at only having one version of a package in a suite-type-component-architecture quadruple. You can have different versions in different architectures and/or components within the same suite. (Even different versions of a architecture all package in different architectures of the same suite). But within the same architecture and the same component of a distribution it is not possible.
Edward Savage wrote:
http://anonscm.debian.org/gitweb/?p=mirrorer/reprepro.git;a=blob_plain;f=doc...
3.1) Can I have two versions of a package in the same distribution? ------------------------------------------------------------------- Sorry, this is not possible right now, as reprepro heavily optimizes at only having one version of a package in a suite-type-component-architecture quadruple.
My reading of the above, is that it's fine *iff* you have different suites for the different versions. So e.g. you have 1.0-1 for lucid and 1.2-1 for precise -- but uploading a 1.2-2 for precise will delete 1.2-1. Does that suit your needs, and if so, did you try it? PS: if it's not obvious, the suite is set at the top of debian/changelog, and should be reported dpkg-parsechangelog.
On 02/07/12 12:53, Trent W. Buck wrote:
Edward Savage wrote:
http://anonscm.debian.org/gitweb/?p=mirrorer/reprepro.git;a=blob_plain;f=doc...
3.1) Can I have two versions of a package in the same distribution? ------------------------------------------------------------------- Sorry, this is not possible right now, as reprepro heavily optimizes at only having one version of a package in a suite-type-component-architecture quadruple.
My reading of the above, is that it's fine *iff* you have different suites for the different versions. So e.g. you have 1.0-1 for lucid and 1.2-1 for precise -- but uploading a 1.2-2 for precise will delete 1.2-1.
Does that suit your needs, and if so, did you try it?
Nope, I'm after having multiple versions in the same suite. I only really need, say, at most six versions, so I could create multiple repositories and then set something up so that when a file is replaced, it shuffles the to-be-deleted package over to the next repository in the chain, who will do the same.. ..but christ, there HAS to be a proper solution rather than that!
On 07/02/2012 01:58 PM, Toby Corkindale wrote:
Nope, I'm after having multiple versions in the same suite. I only really need, say, at most six versions, so I could create multiple repositories and then set something up so that when a file is replaced, it shuffles the to-be-deleted package over to the next repository in the chain, who will do the same..
..but christ, there HAS to be a proper solution rather than that! hi
in rpm/yum systems there have been some packages where the version no. is rolled into the package name giving "package-1.2" as the package and then attaching a version numbered onto it. VirtualBox-4.1-4.1.16_78094_rhel6-1.x86_64.rpm being the prime example of this. Steve
On 02/07/12 16:13, Steve Roylance wrote:
On 07/02/2012 01:58 PM, Toby Corkindale wrote:
Nope, I'm after having multiple versions in the same suite. I only really need, say, at most six versions, so I could create multiple repositories and then set something up so that when a file is replaced, it shuffles the to-be-deleted package over to the next repository in the chain, who will do the same..
..but christ, there HAS to be a proper solution rather than that! hi
in rpm/yum systems there have been some packages where the version no. is rolled into the package name giving "package-1.2" as the package and then attaching a version numbered onto it.
VirtualBox-4.1-4.1.16_78094_rhel6-1.x86_64.rpm being the prime example of this.
Debian's system supports a similar concept, but I'd like to avoid it, as it breaks automatic upgrades. Surely it should just be possible to store several versions in a repository at once? I'm amazed this seems to be such a rare request.
Toby Corkindale wrote:
Surely it should just be possible to store several versions in a repository at once? I'm amazed this seems to be such a rare request.
It's possible. twb@blood[internal]$ pwd /srv/apt/internal twb@blood[internal]$ ls [A-Z]* Contents Packages.bz2 Sources Contents.bz2 Release Sources.bz2 OpenLDAP-OpenSSL_2.4.21-0ubuntu5.4.diff Release.bz2 Packages Release.gpg twb@blood[internal]$ ls xtables-addons-modules-generic*deb xtables-addons-modules-generic_2.6.32-36_all.deb xtables-addons-modules-generic_2.6.32-37_all.deb xtables-addons-modules-generic_2.6.32-38_all.deb xtables-addons-modules-generic_2.6.32-39_all.deb xtables-addons-modules-generic_2.6.32-40_all.deb xtables-addons-modules-generic_2.6.32-41_all.deb twb@blood[internal]$ grep-dctrl -P xtables-addons-modules-generic -s Version Packages Version: 2.6.32-39 Version: 2.6.32-38 Version: 2.6.32-41 Version: 2.6.32-40 Version: 2.6.32-36 Version: 2.6.32-37
On 03/07/12 12:44, Trent W. Buck wrote:
Toby Corkindale wrote:
Surely it should just be possible to store several versions in a repository at once? I'm amazed this seems to be such a rare request.
It's possible.
Excellent! Are you going to tell me how, or just tease me with proof? :) (Is this still reprepro?)
twb@blood[internal]$ pwd /srv/apt/internal twb@blood[internal]$ ls [A-Z]* Contents Packages.bz2 Sources Contents.bz2 Release Sources.bz2 OpenLDAP-OpenSSL_2.4.21-0ubuntu5.4.diff Release.bz2 Packages Release.gpg twb@blood[internal]$ ls xtables-addons-modules-generic*deb xtables-addons-modules-generic_2.6.32-36_all.deb xtables-addons-modules-generic_2.6.32-37_all.deb xtables-addons-modules-generic_2.6.32-38_all.deb xtables-addons-modules-generic_2.6.32-39_all.deb xtables-addons-modules-generic_2.6.32-40_all.deb xtables-addons-modules-generic_2.6.32-41_all.deb twb@blood[internal]$ grep-dctrl -P xtables-addons-modules-generic -s Version Packages Version: 2.6.32-39 Version: 2.6.32-38 Version: 2.6.32-41 Version: 2.6.32-40 Version: 2.6.32-36 Version: 2.6.32-37
-- .signature
Toby Corkindale wrote:
On 03/07/12 12:44, Trent W. Buck wrote:
Toby Corkindale wrote:
Surely it should just be possible to store several versions in a repository at once? I'm amazed this seems to be such a rare request.
It's possible.
Excellent! Are you going to tell me how, or just tease me with proof? :)
(Is this still reprepro?)
It's using the apt-ftparchive cheapass script I linked to originally.
Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
Nope, I'm after having multiple versions in the same suite. I only really need, say, at most six versions, so I could create multiple repositories and then set something up so that when a file is replaced, it shuffles the to-be-deleted package over to the next repository in the chain, who will do the same..
The package management problem and the revision control problem are not the same, but there is an overlap of requirements. One of the advances of Subversion over CVS, as I recall, was that updates were atomic. Clearly this would be desirable in a package manager too, as would the ability to create branches, revert changes, etc. Former Red Hat developers built a package manager of this sort, but it never formed the basis of a widely used distribution so far as I know. The only other effort in this direction that I am aware of is the use of BTRFS snapshots to revert rpm upgrades; but I don't think the file system level is the best place for this unless all of the files controlled by the package manager are in a single hierarchy. I suppose that's one of the motivations for the "/usr merge".
participants (5)
-
Edward Savage -
Jason White -
Steve Roylance -
Toby Corkindale -
Trent W. Buck