Skip to content
This repository has been archived by the owner. It is now read-only.

Split pmbootstrap and aports in two repositories #383

Open
ollieparanoid opened this Issue Aug 14, 2017 · 9 comments

Comments

Projects
None yet
6 participants
@ollieparanoid
Copy link
Member

commented Aug 14, 2017

There are different release cycles, that make sense for aports and pmbootstrap.

  • aports: always up-to-date
    • we could provide different branches like edge, 3.6, 3.5 which follow Alpine's branching model
    • but these branches need to be always up to date
  • for pmbootstrap we could have a stable release every now and then
    • that way we could package it for pip and for some Linux distributions (AUR, Gentoo overlay, ...)
    • it would be a better experience for new users (install pmbootstrap through their distribution/pip, more stability)

A great benefit, that @MartijnBraam pointed out:

if you ship pmbootstrap seperately, then you can make pmbootstrap init manage the aports git repo and make it selectable between "edge", which is the latest master or a specific tag

@yuvadm

This comment has been minimized.

Copy link
Member

commented Aug 22, 2017

I'd be interested to start working on this packaging task. Would love to hear your thoughts on how we should handle this. Specifically the biggest pain point is the assumption that aports is under the working directory.

In this future split, where would be the right place to have aports? Within .var/local/pmbootstrap perhaps? Should pmbootstrap handle the loading of aports?

Note that currently in the setup.py proposed in #443 the use of the -p aports flag is required when running the installed executable entry point.

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2017

Tough question and I'm almost out of postmarketOS time for today :/

I would like pmbootstrap to assist the user in getting the aports repository, so that no manual step is involved. It would need to happen before the first question in init, because that shows the list of devices, which we can only do when the aports folder is available.

The work path seems to be suitable for aports, so we would need to ask for that first.

Here's a rough draft from a user's point of view.

  • pmbootstrap init
  • ask for work folder
  • aports not found (specify with -p)! do you wish to download it to: $work/aports? [y]
    • pulls it with git
    • display instructions how to update them (make that convenient with a pmbootstrap shortcut?)
  • which device do you want to port?
  • ...
@kskarthik

This comment has been minimized.

Copy link
Collaborator

commented Aug 25, 2017

Label this as Long term priority until we get plasma working on already green ports :) Then we are good to go

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

commented Aug 25, 2017

It has a future label already :) But if @yuvadm or someone else wants to work at this right now, why not? It is a blocker for getting pmbootstrap into pypi #327 after all and making the development more robust #382.

@marmistrz

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2018

How about a very simple workflow: if the aports directory is missing, we just show the git clone ... command to the user.

This looks like a very small change which I could do myself, we'd just need to decide the default path for aports.

This issue actually breaks my packaging for AUR (Arch Linux) :)

@MartijnBraam

This comment has been minimized.

Copy link
Member

commented Apr 30, 2018

I guess ~/.cache/pmbootstrap/aports or reuse ~/.local/var/pmbootstrap. I guess making pmbootstrap init fetch the latest aports makes it quite usable.

marmistrz added a commit to marmistrz/pmbootstrap that referenced this issue Apr 30, 2018

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

commented May 1, 2018

Thanks for working on this @marmistrz! Since moving the aports to a dedicated git repository is a big change, there would be some tasks that need to be done beforehand:

  • set up the aports repository (for testing, this doesn't need to be done in the postmarketOS organization on GitHub)
    • start with the pmbootstrap repository
    • delete everything from pmbootstrap, except for the testing code
    • adjust Travis CI testing code
      • only run the tests relevant for the aports
      • make sure building changed packages is still working (we will need to clone pmbootstrap for that!)
  • adjust the pmbootstrap repository (can be done in pull requests)
    • rewrite test cases depending on the aports folder to work without that folder (or disable them if they still run in the "aports" repository)
    • provide a good upgrade path for users (we are already versioning the work folder structure and have migration code, so we could add a new version and add migration code that requires the user to clone the aports folder)

I'm not sure if that covers everything, but that would be a good start from where we could do the first tests and fix whatever else comes up. So all this is quite some work, and while it would be nice if you could look into this, I don't think we should make such a big change in master at least until the next blog post is out at end of May (because preparing for that eats up a lot of resources already).

@PureTryOut

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2018

Now we're moving to Gitlab and thus changing our infrastructure a bit, is it maybe a good time to split the two up? It seems like the perfect opportunity to me.

@ollieparanoid

This comment has been minimized.

Copy link
Member Author

commented Jun 16, 2018

The hard part are the code changes (see above), so I would advise against mixing that up with the gitlab migration, because it would make the migration way more complex.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.