Skip to content
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

Open
maandree opened this issue Jan 24, 2013 · 18 comments
Open

syspony #15

maandree opened this issue Jan 24, 2013 · 18 comments
Labels
Milestone

Comments

@maandree
Copy link
Member

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.

@jaredallard
Copy link

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.

@maandree
Copy link
Member Author

Yes, it is not an issue, this repo is a dedicated roadmap.

Awesome! Personally I do not have too much time at the moment,
but I will continue working soon with the package manager (primarly)
and the boot sequence.
You can help with anything you want, but to make use it does not
conflict with my plan (it is hard to describe a detailed idea without
any working gooding) I would suggest the once marked as "ponfied"
as those can be easily used in any distro and are essential for the
pony experience. You could also work with "mirrorpond", but I rank
that one as low priority as it does ponify the OS experince.

Letter to Celestia panics/oopses are probably very hard and I do not
have too much knowledge how how the Linux-kernel work, if you do
or if you know anypony that does, it would be a great subproject to
work on. Otherwise I suggest "daringdo", "nopony" and "pony-shadow".

If you good at making rhymes, ponysay [which naturally will be a default
package for GNU/Pony] could use some Zecora style error messages.

@maandree
Copy link
Member Author

If you decide on something to help with let me know so I can create a repo. and give you editing permissions.

@maandree
Copy link
Member Author

@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.

@jaredallard
Copy link

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.

@maandree
Copy link
Member Author

If you have any pony related scripts that would be awesome.
If you small scripts you find useful you can contribute them to https://github.com/GNU-Pony/miscellaneous
If you have functions for interactive Bash sessions, you can add them to https://github.com/GNU-Pony/bash.d/tree/master/src

@maandree
Copy link
Member Author

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:
https://github.com/GNU-Pony/spike/blob/master/doc/scroll-specifications
Here is an example of a Spike scroll:
https://github.com/GNU-Pony/spike-repositories/blob/extra/miscellaneous/ponymenu.scroll
Here is the source fo dragonsuite which is used on scrolls:
https://github.com/GNU-Pony/spike/blob/master/src/dragonsuite.py
And the standard I_USE-flags are specified at:
https://github.com/GNU-Pony/spike/blob/master/doc/i_use-flags
And spike -3 <files> is used to calculate the sha3sum of files.


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.

@jaredallard
Copy link

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.

@maandree
Copy link
Member Author

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,
but choose whatever you feel most comfortable with for what you are written.

@maandree
Copy link
Member Author

I have given you access to the following repositories:

applebloom, artwork, bash.d, miscellaneous, sweetie-bot

@jaredallard
Copy link

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.

@maandree
Copy link
Member Author

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.

  • a patch scroll is a scroll that patches another scroll at build time to extend or modify it.

@jaredallard
Copy link

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.

@maandree
Copy link
Member Author

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:

  1. Sweetie Bot crawls and converts other repositories
  2. Somepony make sure it is correct and starts automaintaining it with Celestia
  3. Celestia create a Spike scroll for every new version, include the version at when it was converted
  4. Dragon Fire autouploads it to spike-repositories/spool
  5. Some other pony, or the same pony, verifies the package's correctness and promotes it to spike-repositories/core,
    spike-repositories/extra or spike-repositories/more.

@jaredallard
Copy link

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.
Oh, also, is sweetie-bot meant to run on GNU/Pony, or run on a different operating system? Since, It'd be easier for me to intergrate apt-get into this, but if I have too I can create a bash-based crawler for it.

@maandree
Copy link
Member Author

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.

@jaredallard
Copy link

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.

@maandree
Copy link
Member Author

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
every distro has a module that is source:d (via the . command) and the function start
is used to begin crawling and converting, until then not commands should execute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants