Re: What do you wish for in an package manager?
Ben Collins writes ... You are missing the fact that the old package does not understand that the new package possibly setup some things (configuration settings, diversions, symlinks, removal of cruft, alternatives) that it cannot recover from. You are missing the fact that it is not as simple as replacing files. HP-UX's Software Distributor (SD) package manager(starting with 11.0) supports the ability to roll back patches. It saves every file that the patch replaces in a save directory, which consumes lots of disk space. When you decide you're happy with the patch or you need the disk space back, which ever comes first :) , then you commit the patch and it removes the save dir and info in the package database. Adam Lazur writes ... Relocatable packages so a user can do an individual package install into ~ without being r00t (this may be possible now with some dpkg foo?). HP-UX's SD also supports relocatable packages. I think this was originally done for diskless support. It requires that people writing install scripts follow strict guidelines to ensure that their packages are indeed relocatable. Richard Atterer ... Just one simple small thing for me, please: An installer that is smart enough to realize that it is about to overflow the disc, so it deletes any .deb files that have been downloaded and already installed. (This bit me once while doing an install over PPP.) SD looks at packages and determines disk usage in each of the standard file system partitions that HP-UX ships with to make sure there is enough space to install. This doesn't handle the case where somebody makes /usr/foo a symlink to another partition but it does pretty well. You can override the disk space analysis if you know what you're doing. In the Rambling apt-get ideas thread, Vince Mulhollon writes ... Use a apt-get client to remotely mess with another workstations packages. Messing with only one workstation at a time is boring. How about multicast to configure a hundred workstations instead, all at once? And then have a proxying apt-getd server multicast out the .deb files to all the machines at the same time? SD can do this and has ACLs too. Some other things about SD, - conforms to (and, IIRC, was used to define) the IEEE POSIX 1387.2 Software Administration standard. - has been ported to several commercial UNIX variants as well as MSWindows. - supports hierarchical packages with Bundle - Product - Fileset - File levels. For example most packages have Foo-BIN, Foo-MAN, and Foo-DOC, or Foo-CLIENT, and Foo-SERVER fileset definitions. SD is pretty nice(as far as closed propriatary software goes), but it is pretty large and slow relative to dpkg/apt. If some of these features could be added to dpkg/apt without sacrificing performance/ease-of-use/supportability then that would be pretty cool. -- Matt Taggart [EMAIL PROTECTED]
Re: What do you wish for in an package manager?
On Thu, Jan 04, 2001 at 01:23:43AM -0700, Matt Taggart wrote: In the Rambling apt-get ideas thread, Vince Mulhollon writes ... Use a apt-get client to remotely mess with another workstations packages. Messing with only one workstation at a time is boring. How about multicast to configure a hundred workstations instead, all at once? And then have a proxying apt-getd server multicast out the .deb files to all the machines at the same time? Oh. Feature request for apt: apt-get upgrade -s It would be nice if the 'simulation' should not just the name of the packages to be installed, but the *size* for the download for each package. That way you can decide based on how long an upgrade is going to take if it is worth doing immediately or during 'quiet' times on one's network. eg: libc6 (0/236 KB) locales (1024 KB) Or somesuch ;) James -- James Bromberger james_AT_rcpt.to www.rcpt.to/~james IT, Pelican Manufacturing - www.pelicanmanufacturing.com.au Snr Web Systems Admin, JDV - www.jdv.com * www.hartleypoynton.com.au Remainder moved to http://www.rcpt.to/~james/james/sig.html pgpJbiPNjAIeQ.pgp Description: PGP signature
Re: What do you wish for in an package manager? Here you are!
Hello Petr Èech wrote: Adam Lazur wrote: The ability to install more than one version of a package simultaneously. Hmm. SO you install bash 2.04-1 and bash 2.02-3. Now what will be /bin/bash 2.04 or 2.02 version? You will divert both of them and symlink it to the old name - maybe, but but how will you know, to what name it diverts to use it? Give me please 3 sane examples, why you need this. And no, shared libraries are NOT an excuse for this. I or my University needs such a functionallity: We use already such a system under Solaris which you can find on www.modules.org This works quite well for us with Solrais, but we have to recompile each Package, we want to install... As Debian has already a large Number of Packages it would be impracticle for us to do all the work again... So why not let the Package Mangement do it... O.K. Here are a few examples, why we need such system... Our Software is installed on decentarlized fileserveres for many Useres whith different tasks and projects. The Sys-Admin can not be able to check if an old version is still needed or if someone dislikes the new Version, here are some User-Space Programms, which will or would have produced Problems due to a lag of compatibility with older Versions You cannot use some Version of Documents created with lyx 1.3 in 1.5 as the file Format has changed at some Places, while the unknown users which have to use such a Programm are not able to fix their Problems on their own. Or they have not enough time to port their Files to new Version, so if the Sysadmin would have killed the older Version and replaced with the new one some projects would have had more work than switching to the new Version Think of some gcc versions... you used a trick to get Your programm work, and then some Specifications changed and your Programm will not compile any more... This could be your Diplomatheses which could be in Danger! Or Gimp us not able any longer to read gifs, but some users don't know any other program, but want to use gif, so they can use the older version... Or the User-Interface has been changed and the User is not willed or has not the time to learn the User-Interface of the new Version Some users might want to live on the bleading edge and others want to have their version forever, and others want stable well tested Versions of programms... And the users like our Module-system and they miss it on Debian... I hope this are enogh Arguments for a Modulesystem (whith different Versions installed) The current module System has one big disadvantage, it uses the PATH environment for version switching, and as the space in the enviroment is very limited we use env-Modules Modules which kontain many other Programs. If we would like to konvert Debian Packages to Modules we only could load about 14 Modules and then our Path becomes too long. So we would still have to rebuild env-Packages... A new Idea from me is, let the Module System create Symlinks under the Users Home directory to Programms and Libaries Docs he wants to execute or to see, then the Path and LD_Path is very short... A typical link would look like this /home/use/.Modules/usr/bin/emacs - /app/modul-system/arch/emacs/20.1/usr/bin/emacs ^ Here would the standard Debian Package be extracted The Addition of a Module would mean: Check for Package Dependencies and install/remove them first... (Ask the User, to do this!) Link all Files of the Package to the User's Homedircetory The Removement of a Module would mean: Check Module Dependencies, aks if some other Modules should also be removed... Look at the ModuleDirectory and unlink all files from the User's Homedirectory... This Method has three disatvanages... 1) It need Symlinks which could be expensive on Systems with 1000 Users and 1000 Programmms (Files) 2) It only works on a per User Base and not on a per Shell Base (which is sometimes confusing the Users) 3) Not Standard Conformant But some big Advantages 1) No need For reloading all the Modules again and again 2) No need for Recompilation or Modification of Debian-Packages... 3) Should work right out of the Box What do you think? Yours Thorsten Wilmer
Re: What do you wish for in an package manager? Here you are!
== Thorsten Wilmer [EMAIL PROTECTED] writes: Hello Petr Èech wrote: Adam Lazur wrote: The ability to install more than one version of a package simultaneously. Hmm. SO you install bash 2.04-1 and bash 2.02-3. Now what will be /bin/bash 2.04 or 2.02 version? You will divert both of them and symlink it to the old name - maybe, but but how will you know, to what name it diverts to use it? Give me please 3 sane examples, why you need this. And no, shared libraries are NOT an excuse for this. The only useable way is to have /bin/bash allways point to a stable version. Apart from that, anyone who cares what version to use must use the full path to the binary or a versioned name, like /bin/bash-2.04-1. I would like binaries to be compiled to reside in versioned directories but I also see a lot of problems with it as well. Especially with the /etc /usr /usr/share and so on. Every directory would have to have a subdir for every package that has files there. What a chaos. Of cause in spezial cases you can install all packages to /usr/share/software/package-version/ and symlinc, but thats not a general solution to the problem. For stuff like /bin/sh a network filesystem doesn't work. MfG Goswin
Relocatable source packages (Re: What do you wish for in an package manager? Here you are!)
On Sat, Jan 06, 2001 at 07:37:21PM +0100, Goswin Brederlow wrote: Apart from that, anyone who cares what version to use must use the full path to the binary or a versioned name, like /bin/bash-2.04-1. I would like binaries to be compiled to reside in versioned directories but I also see a lot of problems with it as well. Especially with the /etc /usr /usr/share and so on. Every directory would have to have a subdir for every package that has files there. What a chaos. Of cause in spezial cases you can install all packages to /usr/share/software/package-version/ and symlinc, but thats not a general solution to the problem. For stuff like /bin/sh a network filesystem doesn't work. It would be very useful to have relocatable source packages. For instance, if DEB_ROOT is set at compile time, the package should prepend its contents to pathnames when trying to find its auxiliary files. For packages which use autoconf, this is as easy as using --prefix. For others, it will probably involve patching the source, but trivially so. The DEB_ROOT used when building should probably go into a control field, so that dpkg can warn if the package is installed somewhere else. dpkg would, of course, also need to include support for unpacking under a different root. This way, packages could be installed to, say, /usr/local/packages/package-version or some such, for situations like the one that started this thread. It would also be a big step toward providing for all the people who seem to want to install .deb's under their home directories and other strange places. Of course, this all turns to shit when you start trying to deal with maintainer scripts (I suppose these could have DEB_ROOT substituted, but probably not without a fair bit of rewriting), daemon programs, and other such nastiness. -- - mdz
Re: What do you wish for in an package manager?
Bam == Brian May [EMAIL PROTECTED] writes: Dwayne == Dwayne C Litzenberger [EMAIL PROTECTED] writes: Dwayne So my question is: What do you wish for in a package Dwayne manager? Run fast, and do not do things like update-something twice when upgrading several packages at once. Bam 1. Built in support for shared NFS systems. Bam See URL:http://snoopy.apana.org.au/~bam/debian/nfs-dpkg/ Bam for some examples. I believe that most of the issues raised here can be solved with higher abstraction. Currently, installation scripts assume too much about the system. The /usr/doc - /usr/share/doc transition problems are one consequence of this. If files were tagged according to some high level criterions, it would be easier to put change the physical location during installation. Setting the path in the package is bad idea from that point of view. I think that installation scripts should be rather declaratives : in fact they should not be scripts. It would avoid security problems because of badly written scripts, and allow easier extensibility by simply interpreting the declarations in a different way, rather than having to rewrite all the scripts of all packages. In short, the current system totally sucks :-) It's cool that it exists, and it does many things, but it has its limits that can't be pushed very far without a complete rethinking of it. (I'm not a subscriber of the list, so if you want me to read your replies, Cc to me) -- Laurent Martelli [EMAIL PROTECTED]http://www.linuxfan.com/~laurent
Re: What do you wish for in an package manager?
On Wed, Jan 03, 2001 at 03:40:21PM +0100, Laurent Martelli wrote:
/usr/doc - /usr/share/doc transition problems are one consequence of
this. If files were tagged according to some high level criterions, it
would be easier to put change the physical location during
installation. Setting the path in the package is bad idea from that
point of view.
I think that installation scripts should be rather declaratives : in
fact they should not be scripts. It would avoid security problems
because of badly written scripts, and allow easier extensibility by
simply interpreting the declarations in a different way, rather than
having to rewrite all the scripts of all packages.
I've had similar thoughts, and I thought that perhaps some of
functions of installation scripts can be replaced by hook scripts that
dpkg would run.
So you'd have something like, say, eight directories at
/usr/lib/dpkg-hooks/{before,after}-{pre,post}-{install,remove}/. Dpkg
would run the scripts in them at the proper times. Each script would
define a file pattern that specifies which packages installations or
removals interest it. So, for instance,
/usr/lib/dpkg-hooks/before-post-install/40_dlconfig could specify that
it wants to be run every time a packages installs a file that matches
/usr/lib/*.so, and run just after unpacking.
I think many of the installation scripts would become unnecessary this
way. Also, it would be possible to change a distribution's behavior
without messing with every package -- a cleaner solution to the
/usr/doc and /usr/share/doc transition problem might be been
possible. And it would be easy to do things that right now are
difficult: for example, a package or the sysadmin could install hooks
to remount automatically some arbitrary filesystem r/o and r/w when a
package install wantes to touch it.
- Adi Stav
Re: What do you wish for in an package manager?
On Wed, 3 Jan 2001, Adi Stav wrote: I've had similar thoughts, and I thought that perhaps some of functions of installation scripts can be replaced by hook scripts that dpkg would run. Something like this is planned for dpkg 1.9, currently in development in cvs. BEGIN GEEK CODE BLOCK Version: 3.12 GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS-- PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z? -END GEEK CODE BLOCK- BEGIN PGP INFO Adam Heath [EMAIL PROTECTED]Finger Print | KeyID 67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG -END PGP INFO-
Re: What do you wish for in an package manager?
On Fri, Dec 29, 2000 at 11:47:44PM +, Mark Seaborn wrote:
They are unrelated if they do not need to communicate (as an
example). If they do not need to communicate, they may as well run on
different machines, in which case they can use different versions of
libc. But I want to be able to merge those two machines into one --
this is what a multi-user system is all about -- and have the two
programs continue to use different libcs.
s/libc/kernel/ and you have a big problem. Use
plex86, VMware or an IBM mainframe. Or a pile of
inexpensive PCs (but hey, you already had that!
How nice!)
As I suggested before, it would be easy if different processes could
have different views on the filesystem. This is feasible on the
Hurd. Linux is not as flexible, unfortunately. I can envisage
You are not up to date; Al Viro has been a busy boy.
Expect process namespaces in 2.5; maybe even as an
additional patches in 2.4.x (x=1). Most of the
groundwork is already there.
Or look at ClusterNFS. Or any of the zillion hacks that
do something similar, with varying levels of success.
modifying libc so that it is possible to redirect files elsewhere on a
per-process basis (ideally this would be done in a general manner so
that a call to open() could be forwarded to a server in another
process, which would then pass back opened fd).
libc ain't enough, really. You'd need to trick the
syscalls, too. For what you describe above, modifying
libc sounds just like extra work. LD_PRELOAD, perhaps.
But the real solution is a kernel-based one. And it's already
designed and waiting for someone like Al Viro to have a month
off. Anyone want to pay him a month worth of salary?-)
(I'm very interested in user filesystems in general. I played with
perlfs last year, but it was too unreliable, and it broke when I
upgraded perl anyway. Modifying libc now seems the way to go, but I'm
not prepared to hack libc on this level yet.)
My current collection of resources is at
http://tv.debian.net/linux/kernel/fs.html
(but that doesn't include most of the stacking material;
I haven't organized it yet)
--
[EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
Perl poetry: for ($tv) { s/blood/caffeine/ while /blood/ }
Re: What do you wish for in an package manager?
Hamish Moffatt [EMAIL PROTECTED] writes: On Wed, Dec 27, 2000 at 01:03:03AM +, Mark Seaborn wrote: Of course. I know this. It is repeated many times on this mailing list. But it does not have to be so. Why should upgrading package X affect unrelated package Y? If one user wants to use packages from Package X and package Y are not truely unrelated if they share any dynamic libraries, though, eg libc. They are unrelated if they do not need to communicate (as an example). If they do not need to communicate, they may as well run on different machines, in which case they can use different versions of libc. But I want to be able to merge those two machines into one -- this is what a multi-user system is all about -- and have the two programs continue to use different libcs. So do you have any suggestion as to how this could actually be implemented? Even if it's actually desirable (which I dispute), implementation seems far from trivial. I just remembered one of my original reasons why this was desirable. :-) At present I find that the barrier to modifying programs is too high; it is too much effort to make a few casual changes to a program. For instance, it has always bugged me that clicking the right button on the arrows on Gtk's scrollbars doesn't scroll in the opposite direction. I expect this is easy to change. One of the problems, after modifying the code, is getting programs to use it. I could install my modified package over the original, but when I'm just testing my hack this is far too slow to do for each little tweak, and it's stupid because my hack could bring down any Gtk program I start up. The other option is to mess around with PATH, LD_PRELOAD, etc., and apart from the fact that it is fiddly and aesthetically displeasing, it is not a generic method and will not work with Perl code, Scheme code, XPM files, or any other arbitrary files that packages contain. I am lazy, and I end up never making these small tweaks because it is not worth the hassle. And I never get drawn in to making bigger changes... As to suggestions for implementation, I have a couple. As I suggested before, it would be easy if different processes could have different views on the filesystem. This is feasible on the Hurd. Linux is not as flexible, unfortunately. I can envisage modifying libc so that it is possible to redirect files elsewhere on a per-process basis (ideally this would be done in a general manner so that a call to open() could be forwarded to a server in another process, which would then pass back opened fd). (I'm very interested in user filesystems in general. I played with perlfs last year, but it was too unreliable, and it broke when I upgraded perl anyway. Modifying libc now seems the way to go, but I'm not prepared to hack libc on this level yet.) Another approach is more on a language level than a system level, and involves creating a better module system (for C, initially) that can also double up as a package system -- something based on the `units' system for Scheme (I've put links to papers describing this at http://members.xoom.com/mseaborn/comp/units/). This is a module system where modules are first class and parametric (while still allowing mutual recursion between modules). Extending it to be typed and to allow the export of macros from modules will make it suitable as a module system for linking everyday C code. Making the interfaces between bits of C code more explicit will make it easier to generate glue code for calling C from other languages. It will make it easier to handle issues associated with interface changes, and spot better when code needs recompiling to handle a macro changing. I intend to work on this some time, so I intend to show by example that it's quite useful. :-) -- Mark Seaborn - [EMAIL PROTECTED] - http://members.xoom.com/mseaborn/ - ``Water boils at a lower temperature at high altitude, which partly accounts for the nasty taste of coffee on the summit of Mauna Kea''
Re: What do you wish for in an package manager?
On Thu, Dec 28, 2000 at 11:23:24PM +, Mark Seaborn wrote: As I suggested before, it would be easy if different processes could have different views on the filesystem. This is feasible on the Hurd. Linux is not as flexible, unfortunately. There are a few ways to do it, but I guess it is quite unrelated to the development of Debian. It's more a topic of linux-kernel or glibc, right? You can also look at fakeroot or the mount --bind option or simply chroot. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: What do you wish for in an package manager?
On Thu, Dec 28, 2000 at 11:23:24PM +, Mark Seaborn wrote: They are unrelated if they do not need to communicate (as an example). If they do not need to communicate, they may as well run on different machines, in which case they can use different versions of libc. But I want to be able to merge those two machines into one -- this is what a multi-user system is all about -- and have the two programs continue to use different libcs. But hang on.. libc should be backwards compatible. If the new version of libc is not backwards compatible with the old, it should have a new major version number. And libcs with different version numbers can already co-exist. So, unless something is broken in libc, there is no need to have multiple versions with the same major number installed. As I suggested before, it would be easy if different processes could have different views on the filesystem. This is feasible on the Hurd. Linux is not as flexible, unfortunately. I can envisage Whoa.. we're well beyond what can be implemented in a package manager now. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: What do you wish for in an package manager?
Hi Hamish Moffatt schrieb: Package X and package Y are not truely unrelated if they share any dynamic libraries, though, eg libc. So do you have any suggestion as to how this could actually be implemented? Even if it's actually desirable (which I dispute), implementation seems far from trivial. It is trivial: link everything statically and include everything that might be needed in each package. Welcome to include-favorite-broken-OS. ciao, 2ri
Re: What do you wish for in an package manager?
Just one simple small thing for me, please: An installer that is smart enough to realize that it is about to overflow the disc, so it deletes any .deb files that have been downloaded and already installed. (This bit me once while doing an install over PPP.) Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ ´` ¯
Re: What do you wish for in an package manager?
* Dwayne C . Litzenberger ([EMAIL PROTECTED]) [001223 22:47]: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? Ideas: Well, I think a coherit method for managing config files and configuration of packages. An easy way to reset a package back to it's prestine settings. A tool to show which packages have been manually configured, configured through a tool, and which one. Policy management. Debian currently sidesteps this by stepping as far away from it as possible, RedHat and TurboLinux force it down your throat. A better system, imho, would be to allow it to be configurable for the PM system. Example: Decide that all daemon's should install 'off' until configured and turned 'on' manually. Ability to do *ALL* package management with source only (ala BSD) complete with diffs instead of getting the whole thing again. The ability to build any version of the binary Package from a complete source (with history (maybe RCS?)). Sort of a FAT SOURCE idea. FAT binaries. Easy methods to relocate paths. Control files that are easy to maintain and version and that can be kept with the source code, upstream, with little or no problem. The ability for the package builder to go get resources itself off the net via URIs. That's about itoh wait: GOOD DOCUMENTATION! Ciao! -- Baldrick, you wouldn't see a subtle plan if it painted itself purple and danced naked on top of a harpsichord, singing 'Subtle Plans Are Here Again.' --Edmund Blackadder II The Doctor What: Not that 'who' guy http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC
Re: What do you wish for in an package manager?
Craig Sanders [EMAIL PROTECTED] writes: On Sun, Dec 24, 2000 at 08:41:43PM +, Mark Seaborn wrote: I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. If this new libc is broken it could bring down the whole system, when what I really want to happen is for the new package to use the unstable libc and everything else carry on using the stable libc. this is the risk you take when you use unstable. if that risk is too great for you, then stick to the stable release. Of course. I know this. It is repeated many times on this mailing list. But it does not have to be so. Why should upgrading package X affect unrelated package Y? If one user wants to use packages from stable, and another user wants to live on the bleeding edge, why should they have to move to different computers? Sure, you could set up a chroot environment for one of the users, but this effectively is the same as using separate machines, and removes many of the advantages of sharing a machine (eg. communication between the two users, and saving disc space by sharing files). it's a small - tiny, even - risk, but it's there. deal with it. the amount of effort and bloat required to implement this idea for the handful of people who would find any use at all for it just isn't worth it. it's a gross violation of the KISS principle and would greatly increase the complexity of systems administration. I strongly disagree. I think it's a matter of finding the right abstractions to make the problem appear simple. when i upgrade a package, i want it to replace the previous version - i don't want to keep the last n versions around just on the off-chance i might have some use for them (e.g. the last 10 versions of libc6 or the last 10 versions of xbooks would waste an enormous amount of disk space). That's fine; an advanced package manager would let you express this preference, and would let more cautious people express their preferences (as well as allowing different preferences for critical packages like libc6 and non-critical packages like xbooks). if i really need more than one version of a library installed, i can compile it in /usr/local and set LD_PRELOAD appropriately. For LD_PRELOAD to work I have to somehow get it into the environments of every program that will start programs that I want to use the new library version. This is particularly difficult for running programs (eg. the GNOME panel). Also LD_PRELOAD only works for C libraries. A better solution might be what Plan 9 does: Each process can have a different view of the filesystem. So you can map different libraries into the filesystem of each process if you want, but leave the rest unchanged. This ought to be doable on the Hurd. -- Mark Seaborn - [EMAIL PROTECTED] - http://members.xoom.com/mseaborn/ - ``I owe a lot to my parents, especially my mother and my father'' -- Greg Norman
RE: What do you wish for in an package manager?
Sorry if I'm a bit late to the party, but I'm going to look into doing something similiar to what Dwayne's doing, with a heavy Java slant. Anyway, I wrote up a wishlist of sorts here : http://www.devel.e-plagiarism.com/~entropy/proposals/jam.html The ideas seem sound, but I haven't had too many people beat on it. It's a rough, first draft, so please don't scream too loudly. Again, it's java-centric. I'd like to be able to create a generic c/c++ capable version later, but at the moment that's a bit more then I want to take on. I'm still looking for any design or just documentation on the thought behind Apt, but it seems woefully unavailable. Before someone says, Go to the Java list *again*, I want thought process, not programming code or language thought. Anyway, enjoy, hope it helps, Matt
Re: What do you wish for in an package manager?
On Tue, Dec 26, 2000 at 09:30:13PM +1030, Matthew Tuck wrote: - if my apt download was terminated halfway through and I have no internet time left, I would still get to install my fully downloaded packages without messing around with dpkg and trying to work out the dependencies manually apt-get -m - Attempt to continue if archives are unlocatable Secondly, the ability to specify higher priorites for certain packages you really want to download, which will download before the lower priorities. Often I want to promote certain packages, because they're new or have important bugfixes or new features I want to see ASAP. apt-get install them first. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: What do you wish for in an package manager?
On Wed, Dec 27, 2000 at 01:03:03AM +, Mark Seaborn wrote: Of course. I know this. It is repeated many times on this mailing list. But it does not have to be so. Why should upgrading package X affect unrelated package Y? If one user wants to use packages from Package X and package Y are not truely unrelated if they share any dynamic libraries, though, eg libc. So do you have any suggestion as to how this could actually be implemented? Even if it's actually desirable (which I dispute), implementation seems far from trivial. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: What do you wish for in an package manager?
Adam Lazur wrote: The ability to install more than one version of a package simultaneously. Hmm. SO you install bash 2.04-1 and bash 2.02-3. Now what will be /bin/bash 2.04 or 2.02 version? You will divert both of them and symlink it to the old name - maybe, but but how will you know, to what name it diverts to use it? Give me please 3 sane examples, why you need this. And no, shared libraries are NOT an excuse for this. Some intelligence for handling multiple machines. Like the ability to nfs mount /usr and have the package manager understand what's going on. sounds like something like --exclude /usr (didn't doogie implement this in 1.8 branch?) Petr Cech
Re: What do you wish for in an package manager?
On Mon, 25 Dec 2000, Petr Èech wrote: Some intelligence for handling multiple machines. Like the ability to nfs mount /usr and have the package manager understand what's going on. sounds like something like --exclude /usr (didn't doogie implement this in 1.8 branch?) No, this is destined for 1.9, when it can be more generic. The patch was rather simple to implement, tho. BEGIN GEEK CODE BLOCK Version: 3.12 GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS-- PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z? -END GEEK CODE BLOCK- BEGIN PGP INFO Adam Heath [EMAIL PROTECTED]Finger Print | KeyID 67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG -END PGP INFO-
Re: What do you wish for in an package manager
Jeffry Smith [EMAIL PROTECTED] writes: download the source, have my machine do the compile, but still have all the dependencies properly worked out (sort of an expanded apt-get -b source). I guess you should get both the ordinary depends and the build-depends. I fail to see where there should be problems. It's just a depency-check. Ohhh, depencies is placed in debian/control and most of the times it is decided on compile time which packages to depend on. That could be a problem if you only want one download phase. Is there examples of packages where build-depends is available but the newly build package is not instalable on the system? (And should this could happen)
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 08:41:43PM +, Mark Seaborn wrote: Dwayne C . Litzenberger [EMAIL PROTECTED] writes: So my question is: What do you wish for in a package manager? I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. If this new libc is broken it could bring down the whole system, when what I really want to happen is for the new package to use the unstable libc and everything else carry on using the stable libc. this is the risk you take when you use unstable. if that risk is too great for you, then stick to the stable release. it's a small - tiny, even - risk, but it's there. deal with it. the amount of effort and bloat required to implement this idea for the handful of people who would find any use at all for it just isn't worth it. it's a gross violation of the KISS principle and would greatly increase the complexity of systems administration. when i upgrade a package, i want it to replace the previous version - i don't want to keep the last n versions around just on the off-chance i might have some use for them (e.g. the last 10 versions of libc6 or the last 10 versions of xbooks would waste an enormous amount of disk space). if i really need more than one version of a library installed, i can compile it in /usr/local and set LD_PRELOAD appropriately. craig -- craig sanders
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger wrote: I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. I'm only familiar with dselect so I guess the new apt stuff might support some of this, but I haven't heard about any of it, so I'll include it here. Firstly, pipeline installation would be very useful. This means: - you install a package as soon as it downloads, while downloading another package - you continue to download and install while a debconf screen is waiting for the user - if my apt download was terminated halfway through and I have no internet time left, I would still get to install my fully downloaded packages without messing around with dpkg and trying to work out the dependencies manually This should make installation faster and better. Secondly, the ability to specify higher priorites for certain packages you really want to download, which will download before the lower priorities. Often I want to promote certain packages, because they're new or have important bugfixes or new features I want to see ASAP. -- Matthew Tuck: Software Developer All-Round Nice Guy My experience is that in general, if there's jobs programming in it, it's not worth programming in. Ultra Programming Language Project: http://www.box.net.au/~matty/ultra/
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 07:54:00PM -0900, Ethan Benson wrote:
personally the plain text database is one of dpkg's greatest assets.
its a royal pain to repair a binary database when it gets fscked. and
yes i have already been saved from a total reinstall through the
ability to fix dpkg's broken database with a text editor.
if your talking about a different database then nevermind.
Berkeley DB to text and back is pretty easy.
Also, I was speaking of binary indices which are even easier to regenerate
if corrupted.
--
Joseph Carter [EMAIL PROTECTED]Free software developer
Crow- these stupid head hunters want resumes in ms word format
Crow- can you write shit in tex and convert it to word?
Overfiend \converttoword{shit}
pgpHnGogir7LX.pgp
Description: PGP signature
Re: What do you wish for in an package manager?
On Sat, Dec 23, 2000 at 10:47:00PM -0600, Dwayne C . Litzenberger wrote: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? dpkg + something to handle package splits/merges a bit more sanely. netbase split to XXX packages php4-cgi-gd and php4-gd merges. How to handle upgrade of php4-cgi-gd to php4-gd? or some kind of a dummy package, which installes and after install it auto-magicaly dissappears. Petr Cech
Re: What do you wish for in an package manager?
* Ethan Benson | personally the plain text database is one of dpkg's greatest assets. | its a royal pain to repair a binary database when it gets fscked. and | yes i have already been saved from a total reinstall through the | ability to fix dpkg's broken database with a text editor. semi-intelligent caching where you check if the text file is newer than the binary file, if so, you use the text file and write a binary copy to the binary file. Else, you just load the binary. Something screws up? Delete the binary file. Make a conffile somewhere so one can choose to use just text, if one has serious size constraints. Saves speed, not very hard to implement (without me having looked at dpkg's code). -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: What do you wish for in an package manager?
Joseph Carter wrote: On Sun, Dec 24, 2000 at 07:54:00PM -0900, Ethan Benson wrote: personally the plain text database is one of dpkg's greatest assets. its a royal pain to repair a binary database when it gets fscked. and yes i have already been saved from a total reinstall through the ability to fix dpkg's broken database with a text editor. if your talking about a different database then nevermind. Berkeley DB to text and back is pretty easy. Also, I was speaking of binary indices which are even easier to regenerate if corrupted. When I talked about binaries, people flamed me ruthlessly and without legitimate reasons. Hope your comments make them grok the point. Having bulky stupid slow text files all around your system is no guarantee of recoverability or reliability, whatever. Such feature comes from smart coding, not that things are text. The ideal system would be that doesn't need your manual intervention to keep things running. Example: checkpointing of package information which we _don't_ have. Some random postinstall file gets fscked and the system stalls, then you gotta fix it by hand. Ah, and if a large portion of the database is gone, there is nothing your stupid hand can do, anyway. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger [EMAIL PROTECTED] said: -- On Sun, Dec 24, 2000 at 11:44:13AM -0500, Adam Lazur wrote: Dwayne C . Litzenberger ([EMAIL PROTECTED]) said: So my question is: What do you wish for in a package manager? Relocatable packages so a user can do an individual package install into ~ without being r00t (this may be possible now with some dpkg foo?). The ability to install more than one version of a package simultaneously. Hmm. That could bring about some problems. It would require a large re-structuring of the filesystem hierarchy. Why would you need this; how important is this to you? Don't see why it would require a restructuring of the filesystem hierarchy. All that I read that as is allowing a user to install binaries into his home directory as himself, and have the package manager know how to find the root db, as well as his. This would be very nice to have, as it would allow normal users to run apt / dpkg / whatever to install things that they run as themselves, and not have to have the root password. One of the strengths of Unix is this ability, but the current packaging doesn't support it (as far as I know). jeff smith - thought for the day: If a guru falls in the forest with no one to hear him, was he really a guru at all? -- Strange de Jim, The Metasexuals
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger [EMAIL PROTECTED] writes: So my question is: What do you wish for in a package manager? I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. If this new libc is broken it could bring down the whole system, when what I really want to happen is for the new package to use the unstable libc and everything else carry on using the stable libc. I want the package system to behave more like a module system for a programming language, particularly a parametric module system such as PLT units. I've put a few e-mails on this topic at http://members.xoom.com/mseaborn/comp/units/, if you want to have a look. -- Mark Seaborn - [EMAIL PROTECTED] - http://members.xoom.com/mseaborn/ - ``Jersey's Crime Prevention Team are out and about, so have you locked up your property?'' -- Roger Bara
Re: What do you wish for in an package manager?
Hi Mark Seaborn schrieb: I want a system where I can install multiple versions of a library (or any package really) and say which version I want each program on the system to use, possibly on a per-user basis. The present system is a disaster waiting to happen: If I install a package from unstable, it often wants to replace my version of libc from stable with one from unstable. [...] You actually can install (hypotetical) libfoo0 (/usr/lib/libfoo.so.0.3.1) and libfoo1 (/usr/lib/libfoo.so.1.0.9) at once, and that's why Debians shared library dependencies work (with packages gradually upgrading to the new library). Unfortunately more and more library packages do no more properly feature the entire soname in the package name, which can cause mayham. And if you want to install packages from unstable on a stable system you ether take the binary package and everything it depends on, or you apt-get -b source it. If all library packages are made properly, you can't get around this with fancy package management. Running programs with another than the standard version of a library can be done with LD_PRELOAD (ld.so(8)). ciao, 2ri
Re: What do you wish for in an package manager?
Dwayne == Dwayne C Litzenberger [EMAIL PROTECTED] writes: Dwayne Hello! I'm starting work on a new linux package manager. Dwayne The idea is to be able to replace rpm, dpkg, apt, dselect Dwayne (backend) with one,written mostly from scratch and Dwayne designed to be as simple (code, not features) and clean as Dwayne possible. For now, the work will be strictly academic, Dwayne but if it works out, it may evolve into future standard Dwayne package manager. Dwayne So my question is: What do you wish for in a package Dwayne manager? 1. Built in support for shared NFS systems. See URL:http://snoopy.apana.org.au/~bam/debian/nfs-dpkg/ for some examples. 2. Get rid of maintainer scripts (don't ask me how...) so that upgrading packages is guaranteed not to destroy your computer, even if the package came an from untrusted source. This could be carried further by saying no daemons can be started by UID=root without express permission by some protected config file. Perhaps maintainer scripts can run from a chroot and/or non-root environment (issues remain unsolved). 3. Other minor issues, eg prevent a package from getting purged but accidently leaving files behind for whatever reason, etc. Actually, but doing 2 you will automatically solve one of the biggest issues in solving 1. -- Brian May [EMAIL PROTECTED]
Re: What do you wish for in an package manager?
Brian May wrote: 2. Get rid of maintainer scripts (don't ask me how...) so that upgrading packages is guaranteed not to destroy your computer, even if the package came an from untrusted source. This could be carried further by saying no daemons can be started by UID=root without express permission by some protected config file. Perhaps maintainer scripts can run from a chroot and/or non-root environment (issues remain unsolved). Won't ask you how :) Here's a MFTL sol'n :) You need to devise a package description/configuration language that is declarative rather than procedural. What comes to my mind would be some sort of logical language, maybe something based on Prolog. That the statements as your example would be implemented with it and then the package interpreter would handle the procedural aspects of upgrading. No religious wars, all right? :) Cheers, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager
Another thing I would like is something like the BSD ports - download the source, have my machine do the compile, but still have all the dependencies properly worked out (sort of an expanded apt-get -b source). -- jeff smith - thought for the day: He that composes himself is wiser than he that composes a book. -- B. Franklin
Re: What do you wish for in an package manager?
exa == exa Eray writes: exa You need to devise a package description/configuration exa language that is declarative rather than procedural. exa What comes to my mind would be some sort of logical exa language, maybe something based on Prolog. That the exa statements as your example would be implemented with it and exa then the package interpreter would handle the procedural exa aspects of upgrading. Sounds like a good idea to me. Just come up with a language that: a) is not dangerous in anyway. b) has the minimum features required for all packages. This might not be possible for all packages (consider ssh which automatically generates a key pair on initial installation). Perhaps a chroot and/or non-root environment could be setup to handle these cases? -- Brian May [EMAIL PROTECTED]
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger [EMAIL PROTECTED] writes: So my question is: What do you wish for in a package manager? I agree with Ethan. Start explaining why you want to reinvent the wheel then we maybe has some ideas for things to do when you reinventing for other reasons. The only feature I've ever tried designing a solution for (and mostly because on some interesting technical problems) is delta/diff packages where you only downloads the changes if that would take lesser time (by some measure).
RE: What do you wish for in an package manager?
Hi guys, So my question is: What do you wish for in a package manager? I agree with Ethan. Start explaining why you want to reinvent the wheel then we maybe has some ideas for things to do when you reinventing for other reasons. If I had to change something in the Debian package manager, I would like it to use bzip2 instead of gzip, but this doesn't need a omplete reimplementation. The problem isn't technical, but it's been debated many times. I don't exactly know the problem w/ this compression except it saves time ;) Anyway, if you think something isn't perfect, you can always help the development of Dpkg, or apt. Sam The only feature I've ever tried designing a solution for (and mostly because on some interesting technical problems) is delta/diff packages where you only downloads the changes if that would take lesser time (by some measure).
Re: What do you wish for in an package manager?
Ethan Benson [EMAIL PROTECTED] wrote: the debian packaging system answered most things i want from a packaging system. what exactly is missing/wrong with the debian packaging system that makes you feel the need for wheel reinvention? I also cannot see anything wrong with the Debian packaging system, but that is just you and me and perhaps some others. From an engineering point of view, true, there is no point in fixing something that is not broken, but from a researching point of view, trying out new things is always desirable, because it increases the diversity of our thoughts. Let's say, what is wrong about the design of cockroaches? They are very strong and flexible, capable of surviving almost in any kind of rough environments. Cockroaches are perfectly fine creatures. The Debian packaging system may also be perfectly fine, but it would most definitely not be the end of history. There are rooms for snakes, birds, dogs, cats, monkeys, Homo Sapiens, and Robo Sapiens. Sometimes trying out different things are just for fun; besides, it is his time. But such activities are important in the long run. I would say this to the original poster: go for it, but please do not invent the same wheels again. Try something different. -- Chuan-kai Lin
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 09:52:47AM +0100, Sami Dalouche wrote: Hi guys, So my question is: What do you wish for in a package manager? I agree with Ethan. Start explaining why you want to reinvent the wheel then we maybe has some ideas for things to do when you reinventing for other reasons. If I had to change something in the Debian package manager, I would like it to use bzip2 instead of gzip, but this doesn't need a omplete reimplementation. The problem isn't technical, but it's been its quite trivial on the level of the packaging system and format, simply put a .tar.bz2 in the ar archive instead of a .tar.gz debated many times. I don't exactly know the problem w/ this compression except it saves time ;) Anyway, if you think something isn't perfect, you can always help the development of Dpkg, or apt. i think the problem is supporting older machines such as 486s. bzip2 is horridly slow on this hardware. and iirc bzip2 takes more memory (or its slower the less memory you have...) since its been discussed before thats all ill say about the subject. -- Ethan Benson http://www.alaska.net/~erbenson/ pgplMCcQvE8zY.pgp Description: PGP signature
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 09:18:09AM +0100, Peter Makholm wrote: Dwayne C . Litzenberger [EMAIL PROTECTED] writes: So my question is: What do you wish for in a package manager? I agree with Ethan. Start explaining why you want to reinvent the wheel then we maybe has some ideas for things to do when you reinventing for other reasons. The only feature I've ever tried designing a solution for (and mostly because on some interesting technical problems) is delta/diff packages where you only downloads the changes if that would take lesser time (by some measure). Dwayne isn't necessarily trying to reinvent the wheel. He said that he wants to build a single tool that does the jobs of all of the tools he listed. Whether or not that is a good approach is debatable, but if the unified tool uses shared code (i.e. libraries) from the other tools in order to do their jobs, it at least shouldn't do the wrong thing for specific operations. He is looking to build a new package manager. I read this as package management tool, not as package management system. But I could be misunderstanding. -- - mdz
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger wrote: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. open up a co-ordination page on sourceforge and start a public design process. do not stick to a religious idea like it should be written in C, or in perl. if you're really doing it for univ./research institute you will need some new features, otherwise the tool you're describing is a simple python/perl wrapper script that provides a common CLI to those tools that you mention. It would call 'em, UNIX way. So you need to give more details on what you want to achieve. Having some concrete goals is very important in this free software enterprise. So my question is: What do you wish for in a package manager? That it isn't just a package manager. It should cook the coffee for me. More importantly: It should be re-usable as a library for implementing packages/modules for PLs· That would make it pretty academic :) As a matter of fact I claimed to Anthony Towns that I'd rewrite dpkg for a test of skill during a friendly exchange. That's one of the features I really want for my future implementation. What do you think? Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Dwayne C. Litzenberger writes: So my question is: What do you wish for in a package manager? Undo. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger wrote: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? Something I have wished for in dpkg is a --rollback option, to undo the installation of a package and revert to the version that was installed previously, without having the original .deb available. And in the light of changed configuration files, it may not even be possible to restore a previous state by just reinstalling the old version again -- Thanks, -o) Matthijs Melchior Maarssen /\\ mailto:[EMAIL PROTECTED] +31 346 570616 Netherlands _\_v
Re: What do you wish for in an package manager?
Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: What do you wish for in an package manager?
Scavenging the mail folder uncovered Wichert Akkerman's letter: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. that's completely crazy. will you force anybody who wants rollback to use raiserfs? generic applications like dpkg should be indipendent of the fs used (as long as the fs provides an adeguate set of features, surely i don't ask for a full-working dpkf on vfat...) federico -- Federico Di Gregorio MIXAD LIVE Chief of Research Technology [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] Don't dream it. Be it. -- Dr. Frank'n'further
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 03:50:41PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Wichert Akkerman's letter: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. that's completely crazy. will you force anybody who wants rollback to use raiserfs? generic applications like dpkg should be indipendent of the fs used (as long as the fs provides an adeguate set of features, surely i don't ask for a full-working dpkf on vfat...) Heh. Do you have any idea how hard it is to implement rollback? Without package support, it is almost impossible without a system layer handling it (snapshot of preinstall state, so you can revert completely back to it). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: What do you wish for in an package manager?
Scavenging the mail folder uncovered Ben Collins's letter: On Sun, Dec 24, 2000 at 03:50:41PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Wichert Akkerman's letter: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. that's completely crazy. will you force anybody who wants rollback to use raiserfs? generic applications like dpkg should be indipendent of the fs used (as long as the fs provides an adeguate set of features, surely i don't ask for a full-working dpkf on vfat...) Heh. Do you have any idea how hard it is to implement rollback? Without package support, it is almost impossible without a system layer handling it (snapshot of preinstall state, so you can revert completely back to it). * dpkg-repack the package (using the installed configuarion files [the only the user can modify/replace]) * copy .deb file to /var/cache/dpkg/rollback/ * install new package * dpkg --rollback remove current package (doea a downgrade) and replaces all the files from the repackaged package * dpkg --clean removes all the repackaged packages. or am i missing something? federico -- Federico Di Gregorio MIXAD LIVE Chief of Research Technology [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] Best friends are often failed lovers. -- Me
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 04:10:43PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Ben Collins's letter: On Sun, Dec 24, 2000 at 03:50:41PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Wichert Akkerman's letter: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. that's completely crazy. will you force anybody who wants rollback to use raiserfs? generic applications like dpkg should be indipendent of the fs used (as long as the fs provides an adeguate set of features, surely i don't ask for a full-working dpkf on vfat...) Heh. Do you have any idea how hard it is to implement rollback? Without package support, it is almost impossible without a system layer handling it (snapshot of preinstall state, so you can revert completely back to it). * dpkg-repack the package (using the installed configuarion files [the only the user can modify/replace]) * copy .deb file to /var/cache/dpkg/rollback/ * install new package * dpkg --rollback remove current package (doea a downgrade) and replaces all the files from the repackaged package * dpkg --clean removes all the repackaged packages. You are missing the fact that the old package does not understand that the new package possibly setup some things (configuration settings, diversions, symlinks, removal of cruft, alternatives) that it cannot recover from. You are missing the fact that it is not as simple as replacing files. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger ([EMAIL PROTECTED]) said: So my question is: What do you wish for in a package manager? Relocatable packages so a user can do an individual package install into ~ without being r00t (this may be possible now with some dpkg foo?). The ability to install more than one version of a package simultaneously. Some intelligence for handling multiple machines. Like the ability to nfs mount /usr and have the package manager understand what's going on. Oh, and a postinstall that'll do not only a diff on conf files that have changed, but allow for a merge as well... .adam -- Adam Lazur, Cluster Monkey 5FE0 559F 37E9 B8BB 8354 B5BF B70C 7A33 F7E9 0FF1
Re: What do you wish for in an package manager?
Federico Di Gregorio writes: or am i missing something? In addition to the things Ben mentioned, dependencies and broken installs. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 09:52:47AM +0100, Sami Dalouche wrote: If I had to change something in the Debian package manager, I would like it to use bzip2 instead of gzip, but this doesn't need a omplete reimplementation. The problem isn't technical, but it's been debated many times. I don't exactly know the problem w/ this compression except it saves time ;) Anyway, if you think something isn't perfect, you can always help the development of Dpkg, or apt. I think if dpkg used some sort of hashed database index it would be a hell of a lot nicer to people's CPUs and memory. Whether or not that requires a re-implemenetation of dpkg or not isn't for me to say since I haven't looked at dpkg's code in 3 years. -- Joseph Carter [EMAIL PROTECTED] GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 * o-o always like debmake because he knew exactly what it would do... ibid o-o: you would ;-)
Re: What do you wish for in an package manager?
Joseph Carter wrote: I think if dpkg used some sort of hashed database index it would be a hell of a lot nicer to people's CPUs and memory. Whether or not that requires a re-implemenetation of dpkg or not isn't for me to say since I haven't looked at dpkg's code in 3 years. That smells like re-write. The scent of painstaking coding. Mmmm. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
On Sun, 24 Dec 2000, Eray Ozkural (exa) wrote: Joseph Carter wrote: I think if dpkg used some sort of hashed database index it would be a hell of a lot nicer to people's CPUs and memory. Whether or not that requires a re-implemenetation of dpkg or not isn't for me to say since I haven't looked at dpkg's code in 3 years. That smells like re-write. The scent of painstaking coding. Mmmm. This is perfectly doable, and on my todo for dpkg 1.9. BEGIN GEEK CODE BLOCK Version: 3.12 GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS-- PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z? -END GEEK CODE BLOCK- BEGIN PGP INFO Adam Heath [EMAIL PROTECTED]Finger Print | KeyID 67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG -END PGP INFO-
Re: What do you wish for in an package manager?
Today, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. Even then, I imagine it to be difficult. What about installs that cross filesystem boundaries, etc. Either you'd have to have transactions on every fs then (and rollback each of them afterwards) or have a trans-filesystem transaction monitor, AFAIK. I'm afraid some serious non-trivial magicks are at work here. Wichert. -- Andreas Fuchs, [EMAIL PROTECTED], [EMAIL PROTECTED], antifuchs Hail RMS! Hail Cthulhu! Hail Eris! All hail Discordia!
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 11:44:13AM -0500, Adam Lazur wrote: Dwayne C . Litzenberger ([EMAIL PROTECTED]) said: So my question is: What do you wish for in a package manager? Relocatable packages so a user can do an individual package install into ~ without being r00t (this may be possible now with some dpkg foo?). The ability to install more than one version of a package simultaneously. Hmm. That could bring about some problems. It would require a large re-structuring of the filesystem hierarchy. Why would you need this; how important is this to you? Some intelligence for handling multiple machines. Like the ability to nfs mount /usr and have the package manager understand what's going on. What do you mean? As it stands, I can mount /usr and /var over NFS and things will work fine. Oh, and a postinstall that'll do not only a diff on conf files that have changed, but allow for a merge as well... Sounds like fun. I suppose it could be made to work to some extent. .adam Thanks for the feedback! -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - See the mail headers for GPG/advertising/homepage information. pgpuW1mJSapxH.pgp Description: PGP signature
Re: What do you wish for in an package manager?
open up a co-ordination page on sourceforge and start a public design process. do not stick to a religious idea like it should be written in C, or in perl. I don't know. I've seem a number of projects fail because they spent too much time on discussion and didn't ever get down to business. I think I'll draft up a design first, then post it for scrutiny. I'll pick the language once the design is set. if you're really doing it for univ./research institute you will need some new features, otherwise the tool you're describing is a simple python/perl wrapper script that provides a common CLI to those tools that you mention. It would call 'em, UNIX way. I don't plan to work around various package managers: I plan to write one that's so much better that people will make the effort of manually redoing their packages. Also, by academic, I meant that this project might not get anywhere useful, and that I don't give a damn for compatibility and kludginess. So you need to give more details on what you want to achieve. Having some concrete goals is very important in this free software enterprise. I agree, although I'm currently in the process of deciding what will be required of this project, so I get things done right. So my question is: What do you wish for in a package manager? That it isn't just a package manager. It should cook the coffee for me. More importantly: It should be re-usable as a library for implementing packages/modules for PLs· Erm, now I'm getting confused. I assume you mean that this package manager should also be a framework for loadable modules. Isn't that way outside the scope of a package manager? Can you give me an example? That would make it pretty academic :) As a matter of fact I claimed to Anthony Towns that I'd rewrite dpkg for a test of skill during a friendly exchange. That's one of the features I really want for my future implementation. What do you think? I think friendly exchange is an understatement. :-) -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - See the mail headers for GPG/advertising/homepage information. pgpvOwF7eTiwg.pgp Description: PGP signature
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger wrote: I wrote.. It should be re-usable as a library for implementing packages/modules for PLs· Erm, now I'm getting confused. I assume you mean that this package manager should also be a framework for loadable modules. Isn't that way outside the scope of a package manager? Can you give me an example? No. I don't think all the things a loader/linker does is useful here. But I do think that in a language that supports modularity, there would be a lot of common things a package manager ought to support. The most obvious and important being dependency information. Which modules use which modules? Less obvious perhaps a recursive namespace implementation. Think subpackages. You can view a package as something that exports/imports symbols perhaps. It doesn't have to be limited to files and directories. What I would want to see is a more abstract view of the process. In fact, one should view this as part of a software-engineering toolchain. It should play nicely with a corresponding build system, config system, etc. Off the top of my head of course. :) Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 02:21:51PM -0500, Joseph Carter wrote: On Sun, Dec 24, 2000 at 09:52:47AM +0100, Sami Dalouche wrote: If I had to change something in the Debian package manager, I would like it to use bzip2 instead of gzip, but this doesn't need a omplete reimplementation. The problem isn't technical, but it's been debated many times. I don't exactly know the problem w/ this compression except it saves time ;) Anyway, if you think something isn't perfect, you can always help the development of Dpkg, or apt. I think if dpkg used some sort of hashed database index it would be a hell of a lot nicer to people's CPUs and memory. Whether or not that requires a re-implemenetation of dpkg or not isn't for me to say since I haven't looked at dpkg's code in 3 years. personally the plain text database is one of dpkg's greatest assets. its a royal pain to repair a binary database when it gets fscked. and yes i have already been saved from a total reinstall through the ability to fix dpkg's broken database with a text editor. if your talking about a different database then nevermind. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpyymQq7oXuH.pgp Description: PGP signature
What do you wish for in an package manager?
Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? Cheers -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - See the mail headers for GPG/advertising/homepage information. pgpjwdtDQMrVo.pgp Description: PGP signature
Re: What do you wish for in an package manager?
On Sat, Dec 23, 2000 at 10:47:00PM -0600, Dwayne C . Litzenberger wrote: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? the debian packaging system answered most things i want from a packaging system. what exactly is missing/wrong with the debian packaging system that makes you feel the need for wheel reinvention? -- Ethan Benson http://www.alaska.net/~erbenson/ pgp6VFfxPZxrY.pgp Description: PGP signature
