-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
syspony #15
Comments
Not exactly an issue, but I guess this is a good way of announcing what you plan to do. Also, if you need any help, I'd be glad to lend some assistance, I guess. |
Yes, it is not an issue, this repo is a dedicated roadmap. Awesome! Personally I do not have too much time at the moment, Letter to Celestia panics/oopses are probably very hard and I do not If you good at making rhymes, ponysay [which naturally will be a default |
If you decide on something to help with let me know so I can create a repo. and give you editing permissions. |
@Jared631 If you still interested in helping, a topological sort (tsort` in coreutils is a simple implementation of one) is needed for spike (the package manager). The topological sort will require some extra features: it should support version ranges for packages as well as fail on circular build dependencies and warn of circular runtime dependencies. One sorting instance may include both types of dependencies. |
Hey, long time no reply, for me. Currently, I'm studying/working with the linux kernel but don't have relly any good knowledge of it to help in that section. But, if you need any bash related scripts, runs, etc. I can quite alot of things with bash, and batch (windows, but it operates almost the same as bash, I made a package manager out of it) So, I can contibute there. |
If you have any pony related scripts that would be awesome. |
One of the most helpful things may be too difficult to do in bash, but if you know any other language or think you can do it in bash, I would be grately appreciated. And that is to write a converter from and package management system you know to Spike scrolls. This will be used on Sweetie Bot, that will be used to autopopulate the package repositories. I you would like to help with this, the specifications for Spike scrolls are found here: Another why to help with Sweetie Bot is to make scripts that fetches (all, not by name) files corresponding to the scrolls (such as PKGBUILD of Arch Linux) (should include how to build, not just install, the package) from other distributions. |
Alrighty, I'll see what I can do about Package 'Porting'. Trust me, I can find a way to do just about anything with bash. Also, by scripts you're talking about are there any /specific/ scripts you'd want besides the one mentioned? I tend to make scripts, etc, better with specific ideas ahead of me. |
You can do anything in Bash, but sometimes I find that it is not worth it and that learning a new language is actually easier. You can just any language at all. Preferable are Bash, Python 3, C and Java, as those are the ones currently used, |
I have given you access to the following repositories: applebloom, artwork, bash.d, miscellaneous, sweetie-bot |
Alright, so, I have a question. When a scroll is being 'used' and such, is it literally being downloaded, compiled from source, then installed? Or is it using pre-compilied packages? Since, for an example, DEBian packages are using pre-compiled binaries in general. |
When you use a scroll the package's source is downloaded and compiled ("build" function), optionally checked for errors ("check" function), and then installed ("package" function). Pre-compiled binares can be used if they are vanilla (no flavour), that is not modified from upstream. If so the scroll's name should end with -bin. Pre-compiled binaries are inferior in the respect that they are harder to customise and make patch scrolls* for, so source scrolls should be included, but offering pre-compiled is useful for those that perfer not to wait for packages to compile, so adding binaries in addition to source is okay.
|
Alright, just kindof hard to see how other package-managers can be ported then, since they almost all offer modified versions of software’s which then makes them work better for their OS. Plus source packages are usually all distributed in a tar.gz, but you still have the modifications. |
Well, that is okay. Sweetie Bot should just do a best effort so there is less to do when adding packages. If the converted scroll is installable but with modifications, then somepony will need to strip out the modification before adding it to the repository. The process of converting and a package to Spike, add it and maintain it will be done in a chain:
|
Alright, I proceed with the script I was currently making then and include both source and pre-compiled binaries w/ modifications, and as you might have guessed yes I'm working on debs through Ubuntu repositories. |
Ideally it is meant to run independently on the distribution, but it is acceptable to but it in a VM with the distribution it is crawling. Additionally, you can add convertion in both directions so it can help other distributions. |
Alright, what I'll do originally is integrate apt-get into it to be used from a ubuntu-vm. Then, once I know it's working, completely, I'll work on a bash-based crawler to enable it to run independently. |
Sounds good. But you could add apt-get for Ubuntu to the sweetie-bot module, I cannot imagine that would be hard. It may be good to move continued discussion to https://github.com/GNU-Pony/sweetie-bot I have started on the Sweetie Bot itself (not distro modules). I have designed it so that |
syspony [or if I get deluged with votes: ponyboot or bootpony (I think those would fit better for a BIOS)], is planned to be developed, but not as a part of GNU/Pony /g.nu:·pony/ as I beleave program should be develop as loosely coupled as possibile. syspony is will be a merge of syslinux and ponysay.
The text was updated successfully, but these errors were encountered: