Operating Systems > Linux and UNIX

Source-package management

<< < (2/4) > >>

piratePenguin:

--- Quote from: worker201 ---You're going to write the xml files for each package?  That's a shitload of work.  I thought your plan was to have the devs write the xml files.  But if you want to do the work yourself, then that's cool, I guess.
--- End quote ---
Yea I was always gonna write the XML files. Only question is how much info (configure stuff mainly) I shoulld put in them...

After I have XML files for the (relatively) few packages required for a usable system (that doesn't mean graphical stuff... But Xorg and some WMs, I wouldn''t mind doing) (and the package manager written, of course) I could make a distro that uses them.

worker201:
It would probably be easier in the long run to create a script that dynamically creates the xml file.  All the appropriate information could be pulled straight from the configure file, given the right kind of reader.  Then all you have to do is feed a full tarball to the script, and it would build the package for you.

piratePenguin:

--- Quote from: worker201 ---It would probably be easier in the long run to create a script that dynamically creates the xml file.  All the appropriate information could be pulled straight from the configure file, given the right kind of reader.  Then all you have to do is feed a full tarball to the script, and it would build the package for you.
--- End quote ---
Good idea.

I think I know what way to do this now.
2 programs (actually they'll be libraries in the end, and then there will be a frontend) - one for the configuration, and one for everything else (solving dependencies, package management itself). Whenever the configuration program doesn't have an XML file, it'll notify the user and print the output of './configure --help', and the user can decide what configuration options to use. Or maybe pull the info like you said, and give that to the user.

piratePenguin:
The idea so far:

The frontend is what the user sees and interacts with. The frontend interacts with two libraries - libdependencies and libconfigure (which I'm not so sure about).

libdependencies is used to sort out dependencies. It will be extensible - there will be extensions for it to support packages, users, and various other stuff. libdependencies asks the extensions "do you have X?" (X being a dependency - the name of a package or the location of a file, or whatever the plugin takes.), and the extension replies as appropriate.

If the extension replies with "no", then libdependencies checks it's configuration to see whether it should tell the extension to go fulfill the dependency or ask the user first. All dependencies that get to libdependencies are required (hence libconfigure (part of it's reason for existance is to act as a frontend to libdependencies), which just might be replaced with libsourcepackagemanagement, or something), so when libdependencies tells the frontend that a dependency isn't met right now, the user will only have a choice between having the dependency solved or cancelling installation (or, if it's a configure option that triggered the dependency, then just cancel the configure option).

All the extensions to libdependencies will actually be libraries (I think that's how extensability works most of the time). The extension that deals with packages, say it's called libdeppackages, will itself be extensible. You will be able to install an extension for RPM, which would check the RPM database for packages, Slackware, which would check /var/log/packages for packages, etc. That way, when some package asks for glib2, and you have it installed as an RPM, this package manager won't go get glib2 again, or anything. Another way that could be dealt with is searching for files a package installs, but that'd be too messy.

Jack2000:
nice work pP

Navigation

[0] Message Index

[#] Next page

[*] Previous page