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.

Sign up for GitHub

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

Jump to bottom

Package up Rescuezilla application suite for other distributions to use #13

Closed
shasheene opened this issue Nov 8, 2019 · 0 comments
Closed

Package up Rescuezilla application suite for other distributions to use #13

shasheene opened this issue Nov 8, 2019 · 0 comments
Assignees
@shasheene
Labels
enhancement New feature or request
Projects
Rescuezilla v1.0.6 Milestone Kanban B...
Milestone
v1.0.6

Comments

@shasheene
Copy link
Member

Currently the applications in Rescuezilla are integrated tightly with the rest of the systems. Installing each utility from a deb package would be a cleaner approach and help integrate a graphical partclone frontend into other Linux distributions.

This of course requires changes to the build system, and extracting each application into its own source tree.
@shasheene shasheene added the enhancement New feature or request label Nov 8, 2019
@shasheene shasheene changed the title Package utilities for other distributions to use Package up Rescuezilla application suite for other distributions to use Mar 29, 2020
@shasheene shasheene self-assigned this Mar 29, 2020
@shasheene shasheene mentioned this issue Apr 2, 2020
Closed
@shasheene shasheene added this to To do in Rescuezilla v1.0.6 Milestone Kanban Board via automation Apr 2, 2020
@shasheene shasheene added this to the v1.0.6 milestone Apr 2, 2020
@shasheene shasheene moved this from To do to In progress in Rescuezilla v1.0.6 Milestone Kanban Board May 18, 2020
shasheene added a commit to shasheene/rescuezilla-dev that referenced this issue May 20, 2020
@shasheene
Extracts frontend apps into separate source trees
9bc9550 
Extracts the rescuezilla frontend, the graphical-shutdown app, and the
(currently de-emphasized) drivereset frontend into separate directories. This
slightly improves modularity, since the src/chroot/ directory no longer
contains the applications themselves.

The PNG files formerly shared between rescuezilla frontend and the (currently
de-emphasized) drivereset frontend have been duplicated where relevant.

This change is in preparation for packaging the applications up as deb files
 rescuezilla#13), so the earlier rationale for using the tertiary /usr/local FHS (File
Hierarchy Standard) hierarchy is now invalid: the frontends when packaged are
expected to be deployed well beyond the official Rescuezilla live environment,
so can certainly no longer be considered scripts developed by the system
administrator of the system it is deployed on. Therefore, the applications need
to reside in the secondary hierarchy (/usr/) rather than tertiary hierarchy
(/usr/local/).  This commit makes these changes as appropriate.

For reviewability, this commit does not modify the build scripts much, other
than making the build script create the rescuezilla desktop shortcut, rather
than a symlink file managed by git.
shasheene added a commit that referenced this issue May 22, 2020
@shasheene
Extracts frontend apps into separate source trees
6c3a8e1 
Extracts the rescuezilla frontend, the graphical-shutdown app, and the
(currently de-emphasized) drivereset frontend into separate directories. This
slightly improves modularity, since the src/chroot/ directory no longer
contains the applications themselves.

The PNG files formerly shared between rescuezilla frontend and the (currently
de-emphasized) drivereset frontend has been duplicated where relevant, and the
file pixmap/redo-icon.png was renamed to be relevant to rescuezilla, even
though it's icon is still redo's. The paths that drivereset shared with
rescuezilla (eg, /usr/share/rescuezilla) have also been updated to reflect
these are two independent applications.

This change is in preparation for packaging the applications up as deb files
 #13), so the earlier rationale for using the tertiary /usr/local FHS (File
Hierarchy Standard) hierarchy is now invalid: the frontends when packaged are
expected to be deployed well beyond the official Rescuezilla live environment,
so can certainly no longer be considered scripts developed by the system
administrator of the system it is deployed on. Therefore, the applications need
to reside in the secondary hierarchy (/usr/) rather than tertiary hierarchy
(/usr/local/).  This commit makes these changes as appropriate.

For reviewability, this commit does not modify the build scripts much, but
since drivereset was split off from rescuezilla changes were made to maintain a
working build: the build script copies the new application directories into the
destination tree, and creates a rescuezilla desktop shortcut (rather than a
symlink file managed by git).
shasheene added a commit to shasheene/rescuezilla-dev that referenced this issue May 22, 2020
@shasheene
Packages and deploys Rescuezilla apps as deb pkgs
71ce8ef 
Packages up the Rescuezilla app suite (rescuezilla frontend, the de-emphasized
'drivereset' app and the graphical shutdown app) as deb files, then deploys
them into the Rescuezilla live environment constructed by the build scripts.
The list of runtime dependencies related to these applications have been moved
from the build scripts into the respective debian package metadata files, with
the Rescuezilla build script then using gdebi to deploy the Rescuezilla
packages and automatically install runtime dependencies during the construction
of the Rescuezilla ISO image.

The deb files generated should be able to be installed on any Debian or Ubuntu
package environment. However the bulk of development, testing and support
remains on the Rescuezilla live ISO image, which is a known/controlled
environment. Integrating Rescuezilla into other Linux distributions will remain
discouraged until Rescuezilla matures.

The boilerplate directory "debian/" was first generated for the rescuezilla
frontend app using [1], then manually modified (and graphical-shutdown and
drivereset were just based on the changes made for the Rescuezilla frontend)

[1] sudo DEBFULLNAME="Shasheen Ediriweera" dh_make --single --yes \
--email='rescuezilla@gmail.com' --copyright=gpl3 --file \
../rescuezilla-1.0.5.1.tar.gz

Fixes rescuezilla#13
shasheene added a commit that referenced this issue May 22, 2020
@shasheene
Extracts frontend apps into separate source trees
cb3ff47 
Extracts the rescuezilla frontend, the graphical-shutdown app, and the
(currently de-emphasized) drivereset frontend into separate directories. This
slightly improves modularity, since the src/chroot/ directory no longer
contains the applications themselves.

The PNG files formerly shared between rescuezilla frontend and the (currently
de-emphasized) drivereset frontend has been duplicated where relevant, and the
file pixmap/redo-icon.png was renamed to be relevant to rescuezilla, even
though it's icon is still redo's. The paths that drivereset shared with
rescuezilla (eg, /usr/share/rescuezilla) have also been updated to reflect
these are two independent applications.

This change is in preparation for packaging the applications up as deb files
 #13), so the earlier rationale for using the tertiary /usr/local FHS (File
Hierarchy Standard) hierarchy is now invalid: the frontends when packaged are
expected to be deployed well beyond the official Rescuezilla live environment,
so can certainly no longer be considered scripts developed by the system
administrator of the system it is deployed on. Therefore, the applications need
to reside in the secondary hierarchy (/usr/) rather than tertiary hierarchy
(/usr/local/).  This commit makes these changes as appropriate.

For reviewability, this commit does not modify the build scripts much, but
since drivereset was split off from rescuezilla changes were made to maintain a
working build: the build script copies the new application directories into the
destination tree, and creates a rescuezilla desktop shortcut (rather than a
symlink file managed by git).
Rescuezilla v1.0.6 Milestone Kanban Board automation moved this from In progress to Done May 22, 2020
@shasheene shasheene mentioned this issue May 29, 2020
Open
@LinuxOpa LinuxOpa mentioned this issue Dec 12, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@shasheene shasheene

Labels
enhancement New feature or request
Projects
No open projects
Rescuezilla v1.0.6 Milestone Kanban B...
  
Done
Milestone
v1.0.6
Development

No branches or pull requests
1 participant
@shasheene