linux?
closed account (S6k9GNh0)
Tonight, I'll make a partition on my drive and attempt an LFS. I haven't actually completed one before (for many reasons) however, I've always wanted one for a lot of reasons. I'll give live commentary on difficulties I come across. :D
NOTE: This may not start till the week after next week. I'm buying a new drive and video card for my PC so.... yeah.
NOTE: This may not start till the week after next week. I'm buying a new drive and video card for my PC so.... yeah.
By LFS, do you mean an entire LFS (as in, bootloaders, kernel, initramfs and userland) or just a kernel/ramfs? The latter can be done in a few hours, depending on your internet connection and your processor whereas the former is an organisational shitstorm.
I plan to try a full LFS on Sunday when I'll finally be done with work. I still have absolutely no idea how I'm going to get programs to work. My plan is to download a bunch of packages from GNU (coreutils, binutils, GCC, g++, fdisk, bash, etc), compile them, stick the binaries on a cdrom with ISOLINUX, compile a kernel, stick that all on the disk with a shell script to copy them on to the hard disk (just as a makeshift installation program) and then try booting it with GRUB. I think that much will work, but I have no idea how my init process will work. Is it a simple matter of editing files in /etc/?
I plan to try a full LFS on Sunday when I'll finally be done with work. I still have absolutely no idea how I'm going to get programs to work. My plan is to download a bunch of packages from GNU (coreutils, binutils, GCC, g++, fdisk, bash, etc), compile them, stick the binaries on a cdrom with ISOLINUX, compile a kernel, stick that all on the disk with a shell script to copy them on to the hard disk (just as a makeshift installation program) and then try booting it with GRUB. I think that much will work, but I have no idea how my init process will work. Is it a simple matter of editing files in /etc/?
closed account (S6k9GNh0)
I'm even gonna come up with my own package management system. That'll be fun. :D
I don't think they're actually that hard to make. I can already think of a basic structure.
You have a bunch of command-line tools (who needs a GUI for this sort of thing? GUIs are for web browsers and video players and ballerinas):
Now, all you have to do is have a central database of packages, e.g.
The database stores the URIs of various installable packages, e.g.
(you could get rid of the Installed? column because the Date of Installation is N/A when a package isn't installed).
When you want to install a package,
1. Check you haven't installed it already
If you have, skip to 3, otherwise, continue
2. Install it
3. Check you have the most recent version (check the date last modified on the server vs. your date of installation)
If you do, quit. If you don't, go to step 2.
The big hole in this arises when you want to remove or upgrade packages. For this, I would suggest having a list of files for each package, e.g.
which could look something like
or whatever.
When you want to remove a package,
1. Check you have it (check /var/pkg/packages.db)
2. Find the .lst file for it (in /var/pkg/lists/ or whatever)
3. Delete all the files it created
4. Delete the .lst file
5. Mark as uninstalled in packages.db
To upgrade a package, you can go one of two ways (that I can think of).
1. Delete it and reinstall it
2. Download the new version and overwrite the old files
If you choose to delete and reinstall it,
1. Check it really is out of date (packages.db)
2. Call rm-pkg for it
3. Call add-pkg for it
Otherwise,
1. Check it's actually out of date
2. Download the newest version
3. Extract it
4. Replace all the old files
5. Install new files if any
6. Recreate the .lst file
I would say the second way was probably marginally faster, but also harder to write.
Either updating or searching is the easiest.
Updating:
Download a new packages.db file from a server
Searching
Parse the existing packages.db file and look for what the user entered (or the closest match).
Of course, I didn't even touch on dependencies. That will likely be the most difficult part, unless you rely on package maintainers to tell you what packages their package depends on. Then all you do is fork() and exec() add-pkg on each dependency... the issue being that if you download a program that has 10 dependencies, and each of those has 10 dependencies, and so on, you quickly fill up the process table and start printing seeing a lot more
You have a bunch of command-line tools (who needs a GUI for this sort of thing? GUIs are for web browsers and video players and ballerinas):
add-pkg -- install a package rm-pkg -- remove a package upgrade-pkg -- upgrade a package update-pkg -- update the package list search-pkg -- search for packages |
Now, all you have to do is have a central database of packages, e.g.
/var/pkg/packages.db |
The database stores the URIs of various installable packages, e.g.
+------------------+----------------+------------+----------------------+ | Package Name | Latest Release | Installed? | Date of Installation | +------------------+----------------+------------+----------------------+ | foo | 1/1/1970 | No | N/A | +------------------+----------------+------------+----------------------+ | End of the world | 23/12/2012 | No | N/A | +------------------+----------------+------------+----------------------+ |
(you could get rid of the Installed? column because the Date of Installation is N/A when a package isn't installed).
When you want to install a package,
1. Check you haven't installed it already
If you have, skip to 3, otherwise, continue
2. Install it
3. Check you have the most recent version (check the date last modified on the server vs. your date of installation)
If you do, quit. If you don't, go to step 2.
The big hole in this arises when you want to remove or upgrade packages. For this, I would suggest having a list of files for each package, e.g.
/var/pkg/lists/foo.lst |
which could look something like
foo|/usr/bin/foo:/usr/lib/libfoo.a:/usr/share/lib/libfoo.so |
or whatever.
When you want to remove a package,
1. Check you have it (check /var/pkg/packages.db)
2. Find the .lst file for it (in /var/pkg/lists/ or whatever)
3. Delete all the files it created
4. Delete the .lst file
5. Mark as uninstalled in packages.db
To upgrade a package, you can go one of two ways (that I can think of).
1. Delete it and reinstall it
2. Download the new version and overwrite the old files
If you choose to delete and reinstall it,
1. Check it really is out of date (packages.db)
2. Call rm-pkg for it
3. Call add-pkg for it
Otherwise,
1. Check it's actually out of date
2. Download the newest version
3. Extract it
4. Replace all the old files
5. Install new files if any
6. Recreate the .lst file
I would say the second way was probably marginally faster, but also harder to write.
Either updating or searching is the easiest.
Updating:
Download a new packages.db file from a server
Searching
Parse the existing packages.db file and look for what the user entered (or the closest match).
Of course, I didn't even touch on dependencies. That will likely be the most difficult part, unless you rely on package maintainers to tell you what packages their package depends on. Then all you do is fork() and exec() add-pkg on each dependency... the issue being that if you download a program that has 10 dependencies, and each of those has 10 dependencies, and so on, you quickly fill up the process table and start printing seeing a lot more
perror("fork()"); :P
| I disagree with this, I have only compiled three programs from source on Linux and it was because I wanted to try some experimental features |
It depends what programs you're getting I guess. Find me a Linux binary for the most recent version of bSNES, for example. AFAIK, only the source and Windows binary are available online. And this is not infrequent in my experience.
Maybe it's not as commonplace as I previously made it sound, but it has happened to me on multiple occasions.
| Those repositories are carefully managed and maintained, and I have never had dependency issues when staying within the defined Ubuntu ecosystem. Obviously if you venture outside of it you are going to run into problems |
No, see. That isn't obvious. And it shouldn't be the case.
The repositories are great whe you can use them, but they only have a fraction of all the programs out there.
To think that a single source can maintain a comprehensive list of every useful program in existence is absurd. I don't agree that most users will never have to leave the repositories. In fact I'd say just the opposite.
For a point of comparison, on Windows you can pick and grab anything you want and the odds of it damaging the rest of your system, or preventing other programs from installing or updating is slim to none unless you download a virus or something else that's malicious (for the record, I consider virus scanners "malicious", so those don't count as counterpoints).
It doesn't have a binary for OSX either, does that mean that OSX is difficult to use?
btw, the installation of that software from source takes two commands and in the Ubuntu repositories you can find similar programs
Many software in the repositories are maintained by the community, not by the Distro vendor
I never had this problem on Linux neither...
BTW why are we discussing so much about this topic?
btw, the installation of that software from source takes two commands and in the Ubuntu repositories you can find similar programs
| To think that a single source can maintain a comprehensive list of every useful program in existence is absurd. I don't agree that most users will never have to leave the repositories. In fact I'd say just the opposite. |
| For a point of comparison, on Windows you can pick and grab anything you want and the odds of it damaging the rest of your system, or preventing other programs from installing or updating is slim [...] |
BTW why are we discussing so much about this topic?
| Many software in the repositories are maintained by the community, not by the Distro vendor |
Not to mention Canonical being a massive company.
Topic archived. No new replies allowed.