Re: private debian pools
On Mon, Dec 09, 2002 at 09:06:23AM +0100, Ola Lundqvist wrote: If you do not mind I can help you and you can help me to improve the debarchiver package. I would be happy to include your scripts there. At the moment I am busy with DAK, but if you want to take over maintaining my scripts as a simpler solution, go ahead ;-). -- Brian May [EMAIL PROTECTED]
Re: private debian pools
On Mon, 2002-12-09 at 02:09, Nick Phillips wrote: On Monday, December 9, 2002, at 12:03 pm, Scott James Remnant wrote: I disagree that this is needed, not for any of the usual reasons, but for the simple reason that this functionality already exists. In part; it's not visible to the user, and it's not possible for a package to specify that it depends on a version of a package from a particular release/distribution/origin. It's entirely visible to the user! When all else fails, apt-cache policy tells you everything you might want in your preferences file. The namespace of an apt repository is its URL, and any information available in a Release file at that URL. Which is inadequate; how do you tell whether the following lines access the same distribution? deb http://debian.lemon-computing.com/debian/ stable main contrib non-free deb http://debian.otago.ac.nz/debian/ stable main contrib non-free A Release file is present for both distributions, in which the following line exists: Origin: Debian Then you can put something like: Pin: release o=Debian in your preferences file to refer to it. If Origin were Ximian for example, you'd put this instead: Pin: release o=Ximian I imagine the problem you had was that the system had all the Ximian GNOME debs installed, and you wanted to use those from Debian instead. That could have been easily solved by putting the following in /etc/apt/preferences: Package: * Pin: release o=Debian Pin-Priority: 1000 Package: * Pin: origin ftp.ximian.com Pin-Priority: -1 In effect, Debian packages can force a downgrade of anything, do not consider Ximian packages for installation at all This is great, but it doesn't enable *packages* to specify what they need. Which is where the logic needs to be, if we really want to avoid problems. Why? I would say that this is the last thing you want to do? A package shouldn't care that Ximian's version of libgal is installed, just that libgal is installed - I (as the user) should then be able to choose which package I install. Scott -- Scott James Remnant Have you ever, ever felt like this? Had strange http://netsplit.com/ things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: private debian pools
On Mon, 9 Dec 2002, Nick Phillips wrote: On Monday, December 9, 2002, at 10:48 am, Fabio Massimo Di Nitto wrote: I do not agree with you for different reasons. First of all noone forces people to add private archives to their sources.list. If users do that they should know that things can break more easily. Sometimes private archive are really usefull for pre-testing pkgs before they enter debian. And sometimes third-party archives are useful because a third party has the resources and inclination to look after something we don't (yet). I agree. Are you seriously saying that you don't want this to be made more reliable because no-one forces people to use such archives, and they should know that [if they use these archives] things can break more easily? What I understood from your message is that you would not like to see around too many private archive because of Debian providing a full system to build them, am I right or I misunderstood something? (because of possible breakage and so on..) The contents of private archive is often (if not always) marked as experimental/unofficial and yes I am serious when I say users should know what can happen adding private archives. Just look at www.apt-get.org and you will notice how many are marked unofficial/experimental.. I do not believe that users cannot read that. Exactly which bit of trying to make things work better do you think is a bad idea? From your previous message: I dread to think how many versions of things like libgtksomeguicrapthatkeepsmakingabichanges (all mutually conflicting, and all required by something you *really need*) we'll end up with if people are easily able to maintain separate repositories. This could be a problem that raise up only if the archive/pkg maintainer is not keeping track of what is going on around. /me points out how much duplicate work has been and how many redundant entries are mentioned on www.apt-get.org My point is that I would like to be able to maintain easily my archive. most of pvt archive provides just one arch and/or one/two releases. I maintain all 3 releases and for like 6 archs with autobuilders and so on and anyway people should be able to choose appropriate tools to handle their archive according to what they want to provide. As i see it now not having dinstall packaged is some sort of limitation to users (I do not exclude myself from the list) even if it is available via cvs (as pointed in another message of this thread). Cheers Fabio
Re: private debian pools
Hi On Sat, Dec 07, 2002 at 04:36:58PM +1100, Brian May wrote: I have a set of scripts for creating private debian package pools, available at: URL:http://www.microcomaustralia.com.au/debian/bin2/. Interesting. These scripts will allow you to create and maintain a private archive with multiple distributions, architectures, etc. No database is required. See URL:http://www.microcomaustralia.com.au/debian/ for a sample. If somebody wants to help tidy up this code and package it for Debian, I will be willing to maintain the Debian package for Debian. If you do not mind I can help you and you can help me to improve the debarchiver package. I would be happy to include your scripts there. The package pool thing is what I miss in debarchiver. I also miss the nice daemon feature from mini-dinstall (which I did not know of until today). I can give you cvs access to my machine or move debarchiver code to cvs.debian.org if you like. This probably will involve going through the README file and fixing the things I have labeled FIXME (most of these should be simple to fix, not sure about the bugs in rmfiles yet though). If you want to do any work on it, please let me know simply so I can tell you if I have made any changes (as I do more testing if I find any bugs I may simply fix them without warning). If anyone else is interested, cvs.debian.org might be a good idea, too... A name is required (bin2 doesn't suit IMHO!). Design note: I have tried to make all scripts as simple as possible (except dpkg-scan* which are hacked versions of the Debian programs). This is something I have been thinking about for some time now... :) Everything uses dsc.pm in order to read the *.changes file, to ensure that the programs remain small. What is dsc.pm ? A description reader, you learn something everyday. dpkg-scanpackages and dpkg-scansources have been hacked to take a file with a list of packages as a parameter. Cool. dpkg-scanudebs does the same thing as dpkg-scanpackages but for udebs. Cool too. Ideally the original versions of these packages should support the functionality required, so these hacked versions wouldn't be required. That sounds like a good thing. Regards, // Ola -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: private debian pools
On Sun, 8 Dec 2002, Joey Hess wrote: Fabio Massimo Di Nitto wrote: Why noone have ever packaged the actual debian set of scritps for handling archives instead? Probably because it's too complicated to be of use unless you're managing something on the scale of the debian archive. It's much easier to install mini-dinstall and make a directory for your repository than it would be to install the real dinstall and set up all the database stuff and other stuff it needs. Well it depends on the need. As I pointed out in another msg of this thread people should be able to choose the appropriate archive system according to the requirement of what they have to offer. private repositories laying here and there (http://www.apt-get.org as mentioned in one of the last DWN), and i know for sure that Brian is not the only that will benefit from such scripts. I also had to write my own to handle my archive since i was not really satisfied with the others. Hmm, I wasn't exactly satisfied with mini-dinstall when I started to use it, but it seemed like a much better trade-off to contribute feedback and bug reports than dilute effort with yet another tool to do the same thing. And now I *am* happy with it, except for a couple of bugs. You have a good point here. Now it is clear to everyone that many people have spent time writing their own scripts to handle pvt archive, meaning a lot of duplicate work. My suggestion would be to have some sort of 3 different archive handlers to satisfy users demand. Entry level - one release (sid/sarge/woody), one arch (probably a simple wrapper for dpkg-scanpackages and dpkg-scansource) Medium level - whatever between entry and insane (something like mini-dinstall) Insane level - full archive (dinstall) Eh? Like everyone else on the internet, you have read access to cvs.debian.org for dinstall's source. doh! I always forget about cvs because Im not a real fan of it :-) Regards Fabio
Re: private debian pools
On Sun, Dec 08, 2002 at 11:03:07PM +, Scott James Remnant wrote:
I disagree that this is needed, not for any of the usual reasons, but
for the simple reason that this functionality already exists.
The namespace of an apt repository is its URL, and any information
available in a Release file at that URL.
If two versions of the same package share the same version number,
apt-get gets confused even if the URL and its Release file are
different.
It wouldn't surprise me if this is because apt-get keeps a hash array
similar to:
$package{mypackage}{1.1}{md5sum} = ...
(I haven't checked the code though), so it can only store one
set of details for each given package version.
So the URL is not really a namespace here, the version number is...
--
Brian May [EMAIL PROTECTED]
Re: private debian pools
On Mon, Dec 09, 2002 at 03:09:44PM +1300, Nick Phillips wrote: Which is inadequate; how do you tell whether the following lines access the same distribution? deb http://debian.lemon-computing.com/debian/ stable main contrib non-free deb http://debian.otago.ac.nz/debian/ stable main contrib non-free Based on the Release file??? -- Brian May [EMAIL PROTECTED]
Re: private debian pools
James Troup [EMAIL PROTECTED] writes: Brian May [EMAIL PROTECTED] writes: I looked at katie; it seemed to be a complicated and undocumented mess that was a total overkill for my purpose (eg. I don't need a database). That complicated and undocumented mess has been running the Debian archives successfully and without major incident for over 2 years now; it must be doing something right. I couldn't even guess where I was suppost to start. You could try reading the non-existent documentation... There is some documentation for using it, but is there any for the initial setup? I certainly have read the docs from CVS, but I'm stuck at the installation stage. I can see what installs where from the debian/* packaging, but what I need to do to setup the archive and database isn't clear. Regards, Roger -- Roger Leigh Liberty and Livelihood - Support the Countryside Alliance Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: private debian pools
Brian May (2002-12-07 16:36:58 +1100) : I have a set of scripts for creating private debian package pools, available at: Wonderful. We now have two tools providing almost the same functionality, except only one does package pools (bin2) and only one is mature (mini-dinstall, by Colin Walters). Could we possibly hope for a merger of those two? I'd very much like to have a pool-aware mini-dinstall... Roland. -- Roland Mas Sauvez une souris, mangez votre chat.
Re: private debian pools
On Sun, 8 Dec 2002, Roland Mas wrote: Brian May (2002-12-07 16:36:58 +1100) : I have a set of scripts for creating private debian package pools, available at: Wonderful. We now have two tools providing almost the same functionality, except only one does package pools (bin2) and only one is mature (mini-dinstall, by Colin Walters). Could we possibly hope for a merger of those two? I'd very much like to have a pool-aware mini-dinstall... Why noone have ever packaged the actual debian set of scritps for handling archives instead? as you can see by yourself there are a lot of private repositories laying here and there (http://www.apt-get.org as mentioned in one of the last DWN), and i know for sure that Brian is not the only that will benefit from such scripts. I also had to write my own to handle my archive since i was not really satisfied with the others. To who should the request be addressed? ftp masters? I offer volunteer to pkg them in case, but since Im still not a d-d i can't access them frequently to follow their evolution in time. Fabio
Re: private debian pools
On Sun, Dec 08, 2002 at 02:03:44PM +0100, Roland Mas wrote: Brian May (2002-12-07 16:36:58 +1100) : I have a set of scripts for creating private debian package pools, available at: Wonderful. We now have two tools providing almost the same functionality, except only one does package pools (bin2) and only one is mature (mini-dinstall, by Colin Walters). Could we possibly hope for a merger of those two? I'd very much like to have a pool-aware mini-dinstall... And don't forget debarchiver, which doesn't (yet) support pools, but is in use in a number of places for doing old-style archives, too. I'd honestly prefer to see the actual archive scripts (The One True Archiving Tools, of which all others must, by definition, be emulations) packaged and useable by mere mortals, but the last I'd heard, this was a long way off, and not terribly high on most priority lists. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpBLKkdFPmTn.pgp Description: PGP signature
Re: private debian pools
On Sun, 8 Dec 2002 15:38:26 +0100 (CET), Fabio Massimo Di Nitto [EMAIL PROTECTED] wrote: Why noone have ever packaged the actual debian set of scritps for handling archives instead? Have you ever looked at katie, jenna and the other girls? They can do magic, 99 % of which unneeded in the case of simple private archives. Some time, I will publish my scripts. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: private debian pools
On Monday, December 9, 2002, at 06:41 am, Joel Baker wrote: I'd honestly prefer to see the actual archive scripts (The One True Archiving Tools, of which all others must, by definition, be emulations) packaged and useable by mere mortals, but the last I'd heard, this was a long way off, and not terribly high on most priority lists. /me wonders whether some concept of namespaces in package names would be useful before we make it too easy for world + dog to run large repositories of .debs - Ximian was bad enough on its own, last I had to recover a system from someone using it... I dread to think how many versions of things like libgtksomeguicrapthatkeepsmakingabichanges (all mutually conflicting, and all required by something you *really need*) we'll end up with if people are easily able to maintain separate repositories. Cheers, Nick
Re: private debian pools
On Sun, 8 Dec 2002 15:38:26 +0100 (CET), Fabio Massimo Di Nitto [EMAIL PROTECTED] wrote: Why noone have ever packaged the actual debian set of scritps for handling archives instead? Have you ever looked at katie, jenna and the other girls? They can do magic, 99 % of which unneeded in the case of simple private archives. Not everyone run simple archive. Mine is quite complex and I have to do most of the work by hand to keep it going. Some time, I will publish my scripts. So here is another piece of duplicate work, isn't it? not to blame anyone of course but it just confirm what I wrote before. People would like to have a common and sane way of building private archive. Regards Fabio
Re: private debian pools
On Mon, 9 Dec 2002, Nick Phillips wrote: /me wonders whether some concept of namespaces in package names would be useful before we make it too easy for world + dog to run large repositories of .debs - Ximian was bad enough on its own, last I had to recover a system from someone using it... I dread to think how many versions of things like libgtksomeguicrapthatkeepsmakingabichanges (all mutually conflicting, and all required by something you *really need*) we'll end up with if people are easily able to maintain separate repositories. I do not agree with you for different reasons. First of all noone forces people to add private archives to their sources.list. If users do that they should know that things can break more easily. Sometimes private archive are really usefull for pre-testing pkgs before they enter debian. Cheers Fabio
Re: private debian pools
On Sun, 8 Dec 2002, Joel Baker wrote: On Sun, Dec 08, 2002 at 02:03:44PM +0100, Roland Mas wrote: Brian May (2002-12-07 16:36:58 +1100) : I have a set of scripts for creating private debian package pools, available at: Wonderful. We now have two tools providing almost the same functionality, except only one does package pools (bin2) and only one is mature (mini-dinstall, by Colin Walters). Could we possibly hope for a merger of those two? I'd very much like to have a pool-aware mini-dinstall... And don't forget debarchiver, which doesn't (yet) support pools, but is in use in a number of places for doing old-style archives, too. I'd honestly prefer to see the actual archive scripts (The One True Archiving Tools, of which all others must, by definition, be emulations) packaged and useable by mere mortals, but the last I'd heard, this was a long way off, and not terribly high on most priority lists. I also maintain my own archive and have developed a rether crazy set of scripts to mainain it. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz
Re: private debian pools
On Sun, Dec 08, 2002 at 02:03:44PM +0100, Roland Mas wrote: Wonderful. We now have two tools providing almost the same functionality, except only one does package pools (bin2) and only one is mature (mini-dinstall, by Colin Walters). Could we possibly hope for a merger of those two? I'd very much like to have a pool-aware mini-dinstall... When I last looked at mini-dinstall it didn't seem to try to cater for many of the tasks required for pools, because it doesn't appear to support pools. eg. with pools you need tools to install packages, maintain multiple Packages files for different areas (at or least thats functionality I need), etc. -- Brian May [EMAIL PROTECTED]
Re: private debian pools
On Sun, Dec 08, 2002 at 09:19:52PM +0100, Marc Haber wrote: Have you ever looked at katie, jenna and the other girls? They can do magic, 99 % of which unneeded in the case of simple private archives. I looked at katie; it seemed to be a complicated and undocumented mess that was a total overkill for my purpose (eg. I don't need a database). I couldn't even guess where I was suppost to start. Also I didn't want to interfere with Debian in anyway, eg. by accidently announcing package uploads to the Debian mailing lists and/or closing other peoples bugs when all I did was upload it to my private archive. What is jenna though? I see she is also in the CVS checkout I did ages ago. I may be daft or something, but these names mean absolutely nothing to be when I am trying to get a given task done. Maybe one day these tools will get better documented, I will be willing to setup a database to manage them. Then I probably should also be able to do cool things like have uploads that fix bigs add to the bug report this bug has been fixed in the version in my private archive, see http://.../... for details, for instance. -- Brian May [EMAIL PROTECTED]
Re: private debian pools
On Monday, December 9, 2002, at 10:48 am, Fabio Massimo Di Nitto wrote: I do not agree with you for different reasons. First of all noone forces people to add private archives to their sources.list. If users do that they should know that things can break more easily. Sometimes private archive are really usefull for pre-testing pkgs before they enter debian. And sometimes third-party archives are useful because a third party has the resources and inclination to look after something we don't (yet). Are you seriously saying that you don't want this to be made more reliable because no-one forces people to use such archives, and they should know that [if they use these archives] things can break more easily? Nobody forces people to use unstable (or even testing) either, and putting the relevant lines in your apt.sources can make things break more easily. Does this mean that we shouldn't try to make them work reliably? Exactly which bit of trying to make things work better do you think is a bad idea? Cheers, Nick
Re: private debian pools
On Sun, Dec 08, 2002 at 10:48:30PM +0100, Fabio Massimo Di Nitto wrote: I do not agree with you for different reasons. First of all noone forces people to add private archives to their sources.list. If users do that they should know that things can break more easily. Sometimes private archive are really usefull for pre-testing pkgs before they enter debian. Then you encounter the problem that user X (for instance) modifies fileutils with ACL support and adds it to his/her private archive. User Y modifies the same version of fileutils with, say SE-Linux, and places it online his/her website. User Z, who uses both archives, suddenly finds he/she may get a ACL version of fileutils OR an SE-Linux version of fileutils depending on how X and Y named the versions. Lets assume the ACL version has .x.1 appended to the version, and the selinux version has the .y.1 appended to the version. So the .selinux version will be treated as newer. While it is true that only one version can get installed, IMHO it is not so good that the user doesn't get any warning of the problem. Now user X and user Y realize that there is a problem, and user Y agrees to remove his package, if user X creates a .x.2 version that has both SE-Linux and ACL support. Only now, users who already have .y.1 installed will see version .x.2 as a downgrade, not an upgrade. I think this is dumb. Soory, I don't have any solutions to these specific problems. -- Brian May [EMAIL PROTECTED]
Re: private debian pools
On Sun, 2002-12-08 at 20:51, Nick Phillips wrote: /me wonders whether some concept of namespaces in package names would be useful before we make it too easy for world + dog to run large repositories of .debs - Ximian was bad enough on its own, last I had to recover a system from someone using it... I dread to think how many versions of things like libgtksomeguicrapthatkeepsmakingabichanges (all mutually conflicting, and all required by something you *really need*) we'll end up with if people are easily able to maintain separate repositories. I disagree that this is needed, not for any of the usual reasons, but for the simple reason that this functionality already exists. The namespace of an apt repository is its URL, and any information available in a Release file at that URL. Now, let's use your example of Ximian. The ftp URL of the Ximian debs you were using was probably: ftp://ftp.ximian.com/pub/debian I imagine the problem you had was that the system had all the Ximian GNOME debs installed, and you wanted to use those from Debian instead. That could have been easily solved by putting the following in /etc/apt/preferences: Package: * Pin: release o=Debian Pin-Priority: 1000 Package: * Pin: origin ftp.ximian.com Pin-Priority: -1 In effect, Debian packages can force a downgrade of anything, do not consider Ximian packages for installation at all If we promote the use of third-parties using Release files, they would set the Origin: tag to something useful to them, perhaps in Ximian's case Ximian. All the functionality you want is already there! Scott -- Scott James Remnant Have you ever, ever felt like this? Had strange http://netsplit.com/ things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: private debian pools
On Sun, Dec 08, 2002 at 12:42:15PM +1100, Brian May wrote: d-arch-builder?? (debian-archive-builder) Sounds good. I have renamed the bin2 directory to darchbuilder. (unfortunately Perl objected to the - in the directory name). The new location is now URL:http://www.microcomaustralia.com.au/debian/darchbuilder/. I have also improved on the Readme file. -- Brian May [EMAIL PROTECTED]
Re: private debian pools
Fabio Massimo Di Nitto wrote: Why noone have ever packaged the actual debian set of scritps for handling archives instead? Probably because it's too complicated to be of use unless you're managing something on the scale of the debian archive. It's much easier to install mini-dinstall and make a directory for your repository than it would be to install the real dinstall and set up all the database stuff and other stuff it needs. private repositories laying here and there (http://www.apt-get.org as mentioned in one of the last DWN), and i know for sure that Brian is not the only that will benefit from such scripts. I also had to write my own to handle my archive since i was not really satisfied with the others. Hmm, I wasn't exactly satisfied with mini-dinstall when I started to use it, but it seemed like a much better trade-off to contribute feedback and bug reports than dilute effort with yet another tool to do the same thing. And now I *am* happy with it, except for a couple of bugs. To who should the request be addressed? ftp masters? I offer volunteer to pkg them in case, but since Im still not a d-d i can't access them frequently to follow their evolution in time. Eh? Like everyone else on the internet, you have read access to cvs.debian.org for dinstall's source. -- see shy jo pgpUS7OFUXvuN.pgp Description: PGP signature
Re: private debian pools
Joel Baker wrote: And don't forget debarchiver, which doesn't (yet) support pools, but is in use in a number of places for doing old-style archives, too. Note that mini-dinstall can generate old-style archives too. That's what I use for all my repositories. archive_style = flat -- see shy jo pgpNLRIjY4XgR.pgp Description: PGP signature
Re: private debian pools
Brian May [EMAIL PROTECTED] writes: I looked at katie; it seemed to be a complicated and undocumented mess that was a total overkill for my purpose (eg. I don't need a database). That complicated and undocumented mess has been running the Debian archives successfully and without major incident for over 2 years now; it must be doing something right. I couldn't even guess where I was suppost to start. You could try reading the non-existent documentation... [...] but these names mean absolutely nothing to be when I am trying to get a given task done. like doc/README.names maybe. *plonk* -- James
Re: private debian pools
On Monday, December 9, 2002, at 12:03 pm, Scott James Remnant wrote: I disagree that this is needed, not for any of the usual reasons, but for the simple reason that this functionality already exists. In part; it's not visible to the user, and it's not possible for a package to specify that it depends on a version of a package from a particular release/distribution/origin. The namespace of an apt repository is its URL, and any information available in a Release file at that URL. Which is inadequate; how do you tell whether the following lines access the same distribution? deb http://debian.lemon-computing.com/debian/ stable main contrib non-free deb http://debian.otago.ac.nz/debian/ stable main contrib non-free I imagine the problem you had was that the system had all the Ximian GNOME debs installed, and you wanted to use those from Debian instead. That could have been easily solved by putting the following in /etc/apt/preferences: Package: * Pin: release o=Debian Pin-Priority: 1000 Package: * Pin: origin ftp.ximian.com Pin-Priority: -1 In effect, Debian packages can force a downgrade of anything, do not consider Ximian packages for installation at all This is great, but it doesn't enable *packages* to specify what they need. Which is where the logic needs to be, if we really want to avoid problems. If we promote the use of third-parties using Release files, they would set the Origin: tag to something useful to them, perhaps in Ximian's case Ximian. All the functionality you want is already there! Some, but not all. Cheers, Nick
Re: private debian pools
On Sun, 2002-12-08 at 14:44, Joey Hess wrote: Joel Baker wrote: And don't forget debarchiver, which doesn't (yet) support pools, but is in use in a number of places for doing old-style archives, too. Note that mini-dinstall can generate old-style archives too. That's what I use for all my repositories. archive_style = flat By the way, this will probably be the default in later versions.
Re: private debian pools
On Sun, 2002-12-08 at 17:26, Brian May wrote: When I last looked at mini-dinstall it didn't seem to try to cater for many of the tasks required for pools, because it doesn't appear to support pools. eg. with pools you need tools to install packages, maintain multiple Packages files for different areas (at or least thats functionality I need), etc. Yes. I think that doing package pools right requires all sorts of extra stuff like some form of database (be it a flat file or PostgreSQL) and special tools for installing/removing package. My feeling is that if you really need pools, what someone needs to do is sit down and package the real dinstall. That way we would have the best of both worlds; a simple, easy to use verison of dinstall in the form of mini-dinstall, and if it doesn't fulfill your needs, then you could go to the real full-blown dinstall.
Re: private debian pools
On Sat, 7 Dec 2002, Brian May wrote: I have a set of scripts for creating private debian package pools, available at: URL:http://www.microcomaustralia.com.au/debian/bin2/. These scripts will allow you to create and maintain a private archive with multiple distributions, architectures, etc. No database is required. See URL:http://www.microcomaustralia.com.au/debian/ for a sample. It looks nice. I had to write some scripts to maintain my archive but I have been hitting several problems. I will give them a shot but I would like to have some more information on them. If somebody wants to help tidy up this code and package it for Debian, I will be willing to maintain the Debian package for Debian. This probably will involve going through the README file and fixing the things I have labeled FIXME (most of these should be simple to fix, not sure about the bugs in rmfiles yet though). Do you have some documentation done somewhere? I wasn't able to find the README file. If you want to do any work on it, please let me know simply so I can tell you if I have made any changes (as I do more testing if I find any bugs I may simply fix them without warning). Well probably yes. I would love to read the doc (except the code itself) and testing it. A name is required (bin2 doesn't suit IMHO!). d-arch-builder?? (debian-archive-builder) dpkg-scanpackages and dpkg-scansources have been hacked to take a file with a list of packages as a parameter. Did you add the fuctionality or just a simple hack? maybe handling it as an cmd line option (ex: --file-list file) will make life much easier and merge with the original one much faster without breaking the normal functionalities. Looking forward to try it. Fabio
Re: private debian pools
On Sat, Dec 07, 2002 at 11:21:17AM +0100, Fabio Massimo Di Nitto wrote: Do you have some documentation done somewhere? I wasn't able to find the README file. Sorry about that. It is possible that the webserver has somehow been configured not to display README files. For now I have renamed it to Readme. Also I have identified a bug in the last line of installchanges, it tries to move the changes file to the done directory with this perl command: rename($ARGV,done) or die Cannot move $ARGV to done: $!; but perl isn't this convenient, I may have to extract the filename from $ARGV (without the path) and add that to the end of the directory. d-arch-builder?? (debian-archive-builder) Sounds good. dpkg-scanpackages and dpkg-scansources have been hacked to take a file with a list of packages as a parameter. Did you add the fuctionality or just a simple hack? maybe handling it as an cmd line option (ex: --file-list file) will make life much easier and merge with the original one much faster without breaking the normal functionalities. A very simple hack, the first parameter is replaced with a file name, this file is opened and a list of files retreived. It is a 4 to 6 line diff. The dpkg-scanudebs is almost identical but it has a single instance of .deb replaced with .udeb. A --file-list parameter would be good, and an option to use udebs instead of debs. A --file-list option will make the first parameter obsolete though, it is not required. -- Brian May [EMAIL PROTECTED]
