Operating Systems > Linux and UNIX
Source-package management
piratePenguin:
I've had a few ideas (and I'm working on them).
Posted them to my ancient blog @ blogger.com:
http://piratepenguin.blogspot.com/2005/11/source-package-management.html
soooooooooo...... thoughts? Think it'd work well, if it was implemented?
piratePenguin:
OK, here's a better XML file if anyone's interested in this thing, for irssi.
--- Code: ---
irssi is a text-based IRC client.
Enables use of irssi over an IPv6 network.
Use a garbage collector.
Support for perl extensions for irssi.
Build with perl support as a module.
Build with perl support statically linked into the irssi binary.
Build without perl support.
--- End code ---
Just use your imagination for now to find out what exactly the client can do with this information.
--- Quote from: worker201 ---Perhaps something like this could work. Here's what you would need to do, I think. Have your distribution system work like php. Then the source code to all these programs gets dropped into the database. When my computer running FC4 with stops by to pick up the latest release of transcode, the package manager looks at my system, and determines what flags are required to create a package custom-suited to my needs. The package manager then gives these requirements to the distro system, which produces a package custom-fit for me. It would also store a compressed copy of the package in the database, just in case someone else with similar requirements comes for the package.
--- End quote ---
source
Well worker, with this (the thing I was describing back then was nothing like this) system, such a system wouldn't be hard to do.
The hardest bit, by far, would be the configure bit of the XML files. For big packages with many options, that'd be one heck of a bitch.
Oh man. Gaping opportunity for an XUL(or HTML and friends, but that's like, old technology :p. The XUL app could easily be run remotely (what worker described) or installed locally (far easier than with HTML/PHP/whatever), and it'd look like a native application.)-built frontend to this thing.
worker201:
It looks like what you are doing here is making the package do the work. Meaning that the configuration files are package dependent. Then your distroserver has to parse the files and then get down to business. What you are basically doing is asking developers to do it your way, and not their way. They don't like that. If they could agree to a certain way of doing things, they probably would have already.
I think there is a better way. It should be possible for the distroserver to run a ./configure just like any monkey, and then generate the configuration files by itself. Once a config file was created, it could be stored, to make installation of that package faster for the next guy.
I think this would maybe make the whole system more efficient. Because just about every program built with autoconf has --build-target=, --with-shared, --prefix=, and etc. The system can prepare canned answers to each of these, based on the machine, so you get a custom package. That leaves extra time and trouble for the optional components.
So, instead of going to the distroserver and asking for an FC3 package, the distro asks your computer what kind of package it wants. Then it builds a custom rpm (as an example) that is designed for your computer, on the fly, while you wait. This is time-consuming, but you can always use a little bandwidth to entertain during the process.
The reason to do it this way is that all you have to do are find the source tarballs. Every open developer has them. It wouldn't require anything more from anybody else than the current system (or lack thereof) already has. All the burden is placed on you and your program. Yeah, it will be harder for you. But it will be completely unobtrusive to everyone else. I mean, imagine what a pain in the ass it would be, if that sorta lazy programmer at ffmpeg didn't write an XML config file. You'd have to write one for him, and since he doesn't release anything but CVS snapshots, that would maybe be once a week. That's too much work, all because some lazy guy won't do things your way. It would be so much easier to just grab the CVS tarball, and have the machine do all the work.
All the users would have to do is download the app and/or visit the website - everything else is taken care of. It's like the way apt repos are done now, except there's no reason to keep extra binaries on hand for all the different possible flavors of Linux.
And best of all, if there is an important option for the package that I want, I get it. Example there is dvdauthor. It requires png15-devel, but only if the --enable-png flag is set at build time. Dag and Dries, in Fedora aptland, just didn't enable png, eliminating the devel dependency. But then you can't use pngs in your dvd menus. I had to download dvdauthor myself and configure it - the apt package was useless to me.
Just a few thoughts and experiences I have had that might help you design your system.
piratePenguin:
--- Quote from: worker201 ---the configuration files are package dependent.
--- End quote ---
Yea, just like the FreeBSD port's makefiles. Although these XML package files will be far more complicated. But whoever's writing the XML file doesn't have to cover every configure flag. Whatever they think is necessary, just. The frontend could produce the output of './configure --help', and the user could add their own options.
--- Quote from: worker201 ---
What you are basically doing is asking developers to do it your way, and not their way.
--- End quote ---
I'm not asking anyone to do anything.
This isn't a bid by piratePenguin to take over the world. It's not 2010 yet.
--- Quote from: worker201 ---
I think there is a better way. It should be possible for the distroserver to run a ./configure just like any monkey, and then generate the configuration files by itself. Once a config file was created, it could be stored, to make installation of that package faster for the next guy.
--- End quote ---
I dunno what different system you're talking about.
The XML files I posted are used by the package manager to sort out dependencies and configure options. It asks the user do they want to apply some_patch, do they want to use '--enable-png' and install libpng. Then it patches, installs dependencies (libpng), runs configure with the options the user wanted, and then compiles it.
--- Quote from: worker201 ---
So, instead of going to the distroserver and asking for an FC3 package, the distro asks your computer what kind of package it wants. Then it builds a custom rpm (as an example) that is designed for your computer, on the fly, while you wait. This is time-consuming, but you can always use a little bandwidth to entertain during the process.
--- End quote ---
All that was part of the plan.
--- Quote from: worker201 ---
imagine what a pain in the ass it would be, if that sorta lazy programmer at ffmpeg didn't write an XML config file.
--- End quote ---
I don't expect him to. I could probably set it up so old ffmpeg package files (that's the XML file) will work with new ones (although they won't know about e.g. --enable-something-new until the next update of the package file).
--- Quote from: worker201 ---
And best of all, if there is an important option for the package that I want, I get it. Example there is dvdauthor. It requires png15-devel, but only if the --enable-png flag is set at build time.
--- End quote ---
--- Code: ---
Allow the use of PNGs in your DVD menus.
--- End code ---
Now any frontend can and should (unless you configured the package manager (not the frontend) to automatically accept/reject recommended configure flags) ask you about '--enable-png' and you can decide if you want it or not. If you say yes, it'll check if you have libpng. If you don't have it, it'll install it. If you have an old version, it'll update it.
--- Quote from: worker201 ---
Dag and Dries, in Fedora aptland, just didn't enable png, eliminating the devel dependency. But then you can't use pngs in your dvd menus. I had to download dvdauthor myself and configure it - the apt package was useless to me.
--- End quote ---
Well in this source package manager (remember that's what it will be), you won't have to worry about that.
--- Quote from: worker201 ---
Just a few thoughts and experiences I have had that might help you design your system.
--- End quote ---
Thanks for your input.
A few of the bits I didn't understand (most of the bits I didn't quote/comment on here) - but I think that might be because you misinterpreted what I'm trying to do...
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.
Navigation
[0] Message Index
[#] Next page
Go to full version