From: Richard Dawe Newsgroups: comp.os.msdos.djgpp Subject: Re: gmp Attention: Eli Z Date: Mon, 19 Jun 2000 22:49:48 +0100 Organization: Customer of Planet Online Lines: 106 Message-ID: <394E957C.F2A08F35@phekda.freeserve.co.uk> References: NNTP-Posting-Host: modem-51.indium.dialup.pol.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news7.svr.pol.co.uk 961453131 2366 62.136.40.51 (19 Jun 2000 22:18:51 GMT) NNTP-Posting-Date: 19 Jun 2000 22:18:51 GMT X-Complaints-To: abuse AT theplanet DOT net X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: de,fr CC: Zippo Workers To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hello. Eli Zaretskii wrote: > > Prashant TR wrote: > > > > Eli Zaretskii wrote: > > > > > But only if package maintainers put the appropriate *.dsm files into > > > the distributions. From my experience, crafting a good .dsm file is > > > not a trivial job... > > > > Yeah, that's true. It would be nice if there would be some software > > to create DSMs automatically based on some input. > > But that's just it: I don't believe the DSM files _can_ be created > automatically. Agreed. zippo does come with a script that takes some of the hassle out of creating a DSM (it fills in some of the standard fields). It's on my to-do list to write a program to help with DSM creation. Ideally this would use the database of available packages to allow easy selection of dependencies (*). (*) Not so easy that it allows people to make packages that require all the latest packages. That really irritates me about using rpm on Linux - I seemingly have to upgrade multiple packages just to get a .1 version increase in something. Anyway, sorry about the rant. > The ones I wrote required non-trivial reasoning and several changes. > > Here are some items I needed to consider: > > - What other programs/packages are related to this one (for the > depends-on and requires clauses)? For example, Make depends on Bash > for running Unix Makefile's, on emu387.dxe on FPU-less machines, and > on djtzn for files received from remote machines (e.g., in an > archive). These things should be easy to add right now, using simple package dependencies, e.g.: depends-on: bash >= 2.03 There are some rough edges in the dependency-checking code, however. I hope to fix by rewriting it soon. FPU emulation is not one thing I had thought about. The DSM specification has the concept of packages providing certain features - perhaps we need a feature called "fpu" or "floating-point"? The DSM for the DJGPP distribution would then have a line like: provides: floating-point Packages requiring the FPU would then require floating-point to be present: requires: floating-point This would force the DJGPP base package (djdev) to be installed, to provide emu387.dxe. Any packages containing emu387.dxe should also have the provides line in their DSM. You're probably wondering why you'd require djdev to be installed on a computer with an FPU. Well, zippo could have code added to detect whether an FPU is present and then install a virtual DSM describing the processor. This would be analogous to the way it detects the operating system and installs a DSM for it, when the package database is first created. > - Do we need to remove files from old releases, to prevent problems? > For example, Groff 1.10 had a slightly different directory structure > than v1.15 and later; Groff 1.16 removes one of the programs and > renames several man pages or moves them to different subdirectories. We had a discussion on the zippo-workers list some time ago about what should happen when upgrading a package. IIRC the consensus was that the best way to upgrade was to remove the old version and then install the new version. zippo will be able to tell what files have changed since installation (MD5 hashes are taken on installed files), so altered files are handled properly (backed up / user prompted / whatever). It is possible to have two versions of the same package installed, e.g. foo 1.1 binaries and foo 1.2 binaries could be installed. Packages with the same name do not clash by default. Using an analogue of groff above, if these packages foo have different directory structures, then they may clash. In this case, a DSM directive would have to be added to make them clash, to prevent them from being installed simultaneously. This issue and many other issues need to be added to a DSM-writing HOWTO (also on my to-do list ;) ). > IMHO if you neglect to address these issues, the DSM files really don't > serve users as well as they were supposed to. I recently saw a comparison of package managers on Linuxcare. The thing they seemed to miss was that ease-of-use of packages depends both on the manager and the packages themselves. FYI the zippo home page is here: http://www.phekda.freeserve.co.uk/richdawe/zippo/ Bye, -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]