Proposed Package Maintenance Changes - Revision history

Phenigma: Blanked the page

2013-09-17T18:42:13Z

Blanked the page

←Older revision		Revision as of 18:42, 17 September 2013
Line 1:		Line 1:
	~~= Making Package Management Easier =~~
	~~== Background - Database/Package management system ==~~
	ConfirmDependencies uses the database to install and configure packages for use in an LMCE system. The is extrememly flexible in its ability to manage these packages and ensure that all required dependent packages are properly installed and configured, based on the devices that are installed on each Computer in an LMCE system.
	This system is extremely extensible and allows for multiple operating systems, multiple package management systems, cross OS and Distro repository sharing. Everytime ConfirmDependencies runs it guarantees all devices on a system have proper packages and dependencies installed and that any device configuration scripts are executed prior to use.
	~~The database stores:~~
	~~# a list of all packages that lmce requires for devices~~
	~~# multiple OS and Distro Compatibilities for each package~~
	~~# multiple sources (repositories) for each package.~~
	~~# multiple OS and/or Distro compatibilitees for each of the defined sources.~~
	ConfirmDependencies does an amazing job of trying to find a package anywhere it can. To achieve this it will match a package source based on Distro, then on Operating System. This can be useful, but means that sources from previous distros could end up in sources.list in a current distro. It also means that a redhat source could end up in an ubuntu sources.list (as they match on OS). This is undersireable and not easily selectable with the existing system.
	Currently a new source must be defined each and everytime a new distro is released (intrepid, lucid, precise). A new package compatibility may also need to be defined. This is an extremely large and complicated system. The complexity makes it difficult for people to understand grasp the use of the management system.

	~~== Proposed Database/Package management changes ==~~
	~~The following are my proposed changes:~~
	*Use the Operating System field to seperate different linux releases (Ubuntu, Raspbian, Debian, Redhat, etc.).
	**Currently all Linux based OSes are grouped as one OS.
	**These systems are all different enough to warrant seperation.
	**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.
	**RepositorySource management becomes simpler/easier
	**Packages for an ubuntu system would not match to an alien (ex. raspbian) source, unless explicitly defined as a compatibility.
	**Autogeneration of sources.list at dvd creation, Diskless_Create, etc, becomes much easier with OperatingSystem seperated by flavour this way.
	*Add a column to the Distro table that is Field: BaseRepositoryName, Type: varchar(30), Null: YES, Default: NULL.
	**This will hold the Distribution specific portion of the Repository Name (ex. intrepid, lucid, precise).
	*Add a column to the Package_Source table that is Field: UseDistroInRepositoryName, Type: tinyint(1), Null: NO, Default: 0.
	**This will be a checkbox that tells ConfirmDependencies to add Repository (main)to the BaseRepositoryName (lucid) to the when the checkbox is ticked and BaseRepositoryName is not NULL.
	**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.
	**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.
	*Fix existing data in the database to properly match on source compatibilities.
	*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''

	~~So, to illustrate my point, here is a before picture of the package source definitions:~~

	~~[[File:Packman-before-cleanup.png\|200px]]~~

	And here is an after picture of what a completely cleaned up package source screen in webadmin could look like(if this was applied to previous releases, which it could be, by backporting a small change in ConfirmDependencies.cpp) [note the checkbox I refer to above is not shown here]:

	~~[[File:Packman-after-cleanup.png\|200px]]~~

	Cross OS/Distro dependencies would still be capable of being defined the way they always have. The checkbox, that I refer to above, would be unchecked in this case to prevent the Distro name from being used in the repository field for ConfirmDependencies. In this example assume the checkbox referred to above is not ticked for the first source definition and is ticked for the second source definition. Result: if the package is from ubuntu presice it will be taken from the ubuntu repository and for all other Ubuntu or Debian OSes it would come from the debian stable repository (confirmdependencies prioritizes on distro match first, then OS).

	~~[[File:Packman-example.png\|200px]]~~

	If the package system is maintained well and device templates are created for most conceivable devices and confirmdependencies is used then entire package system could be much more tightly controlled, eliminating many errors and all around making things easier and more automatic from a user perspective.

Phenigma: Undo revision 33876 by Phenigma (talk)

2013-02-20T01:13:02Z

Undo revision 33876 by Phenigma (talk)

←Older revision		Revision as of 01:13, 20 February 2013
Line 26:		Line 26:
	**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.		**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.
	**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.		**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.
	*Fix ~~package~~ source ~~matching bug in confirmdependencies~~.		*Fix existing data in the database to properly match on source compatibilities.
	*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''		*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''

Phenigma: Porting to Ubuntu Linux 1204 moved to Proposed Package Maintenance Changes: Not directly related to 1204

2013-02-19T23:14:01Z

Porting to Ubuntu Linux 1204 moved to Proposed Package Maintenance Changes: Not directly related to 1204

←Older revision	Revision as of 23:14, 19 February 2013
(No difference)

Phenigma: /* Proposed Database/Package management changes */

2013-02-19T22:09:35Z

Proposed Database/Package management changes

←Older revision		Revision as of 22:09, 19 February 2013
Line 26:		Line 26:
	**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.		**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.
	**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.		**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.
	*Fix ~~existing data~~ in ~~the database to properly match on source compatibilities~~.		*Fix package source matching bug in confirmdependencies.
	*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''		*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''

Phenigma at 19:28, 19 February 2013

2013-02-19T19:28:47Z

←Older revision		Revision as of 19:28, 19 February 2013
Line 20:		Line 20:
	**Packages for an ubuntu system would not match to an alien (ex. raspbian) source, unless explicitly defined as a compatibility.		**Packages for an ubuntu system would not match to an alien (ex. raspbian) source, unless explicitly defined as a compatibility.
	**Autogeneration of sources.list at dvd creation, Diskless_Create, etc, becomes much easier with OperatingSystem seperated by flavour this way.		**Autogeneration of sources.list at dvd creation, Diskless_Create, etc, becomes much easier with OperatingSystem seperated by flavour this way.
	*Add selections to Package_Compat
	**Add 2 columns to Package_Compat that are: Field: MatchDistro, MatchOS, Type:tinyint(1), Null: NO, Default: 1.
	**Add 1 columns to Package_Compat that is: Field: MatchAny, Type:tinyint(1), Null: NO, Default: 0.
	**These will be checkboxes to allow the selection of HOW to match a Package Source to a Package for each defined Package Compatibility. Very handy.
	**Selectively control that each package must match Distro/OS/Any Package Source per defined compatibility.
	*Add a column to the Distro table that is Field: BaseRepositoryName, Type: varchar(30), Null: YES, Default: NULL.		*Add a column to the Distro table that is Field: BaseRepositoryName, Type: varchar(30), Null: YES, Default: NULL.
	**This will hold the Distribution specific portion of the Repository Name (ex. intrepid, lucid, precise).		**This will hold the Distribution specific portion of the Repository Name (ex. intrepid, lucid, precise).
Line 31:		Line 26:
	**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.		**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.
	**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.		**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.
			*Fix existing data in the database to properly match on source compatibilities.
	*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''		*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''

Line 45:		Line 41:
	[[File:Packman-example.png\|200px]]		[[File:Packman-example.png\|200px]]

	If the package system is maintained well and device templates are created for most conceivable devices and confirmdependencies is used then entire package system could be much more tightly controlled, eliminating many errors and all around making things easier and more automatic from a user perspective~~. Note: The proposed package compatibility matching selections are not shown in the above graphics~~.		If the package system is maintained well and device templates are created for most conceivable devices and confirmdependencies is used then entire package system could be much more tightly controlled, eliminating many errors and all around making things easier and more automatic from a user perspective.

Phenigma at 19:01, 19 February 2013

2013-02-19T19:01:02Z

←Older revision		Revision as of 19:01, 19 February 2013
Line 5:		Line 5:
	The database stores:		The database stores:
	# a list of all packages that lmce requires for devices		# a list of all packages that lmce requires for devices
	# OS and Distro Compatibilities for each package		# multiple OS and Distro Compatibilities for each package
	# multiple sources (repositories) for each package.		# multiple sources (repositories) for each package.
	# multiple OS and/or Distro compatibilitees for each of ~~those~~ sources.		# multiple OS and/or Distro compatibilitees for each of the defined sources.
			ConfirmDependencies does an amazing job of trying to find a package anywhere it can. To achieve this it will match a package source based on Distro, then on Operating System. This can be useful, but means that sources from previous distros could end up in sources.list in a current distro. It also means that a redhat source could end up in an ubuntu sources.list (as they match on OS). This is undersireable and not easily selectable with the existing system.
	Currently a new source must be defined each and everytime a new distro is released (intrepid, lucid, precise). A new package compatibility may also need to be defined. This is an extremely large and complicated system. The complexity makes it difficult for people to understand grasp the use of the management system.		Currently a new source must be defined each and everytime a new distro is released (intrepid, lucid, precise). A new package compatibility may also need to be defined. This is an extremely large and complicated system. The complexity makes it difficult for people to understand grasp the use of the management system.

Line 17:		Line 18:
	**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.		**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.
	**RepositorySource management becomes simpler/easier		**RepositorySource management becomes simpler/easier
	**Packages for an ubuntu system would not ~~ever attempt~~ to ~~be sourced from~~ an alien (ex. raspbian) ~~repository~~, unless explicitly defined as a compatibility.		**Packages for an ubuntu system would not match to an alien (ex. raspbian) source, unless explicitly defined as a compatibility.
	**Currently it is confusing for devs to determine if a repository could be unintentionally considered as an alternate source (ex. right now a raspbian repository could be considered as an alternative to an ubuntu repository, if a package is not found, because they are defined as the same OS [linux]).		**Autogeneration of sources.list at dvd creation, Diskless_Create, etc, becomes much easier with OperatingSystem seperated by flavour this way.
	** Autogeneration of sources.list at dvd creation, Diskless_Create, etc, becomes much easier with OperatingSystem seperated by flavour this way.		*Add selections to Package_Compat
			**Add 2 columns to Package_Compat that are: Field: MatchDistro, MatchOS, Type:tinyint(1), Null: NO, Default: 1.
			**Add 1 columns to Package_Compat that is: Field: MatchAny, Type:tinyint(1), Null: NO, Default: 0.
			**These will be checkboxes to allow the selection of HOW to match a Package Source to a Package for each defined Package Compatibility. Very handy.
			**Selectively control that each package must match Distro/OS/Any Package Source per defined compatibility.
	*Add a column to the Distro table that is Field: BaseRepositoryName, Type: varchar(30), Null: YES, Default: NULL.		*Add a column to the Distro table that is Field: BaseRepositoryName, Type: varchar(30), Null: YES, Default: NULL.
	**This will hold the Distribution specific portion of the Repository Name (ex. intrepid, lucid, precise).		**This will hold the Distribution specific portion of the Repository Name (ex. intrepid, lucid, precise).
Line 25:		Line 30:
	**This will be a checkbox that tells ConfirmDependencies to add Repository (main)to the BaseRepositoryName (lucid) to the when the checkbox is ticked and BaseRepositoryName is not NULL.		**This will be a checkbox that tells ConfirmDependencies to add Repository (main)to the BaseRepositoryName (lucid) to the when the checkbox is ticked and BaseRepositoryName is not NULL.
	**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.		**If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.
	*No change to existing behaviour, completely backwards compatible.		**Packages for lucid distro would not match to previous (or later) ubuntu distros, unless explicitly defined as a compatibility.
			*'''No change to existing behaviour, completely backwards compatible with previous releases of LMCE and ComfirmDependencies.'''

	So, to illustrate my point, here is a before picture of the package source definitions:		So, to illustrate my point, here is a before picture of the package source definitions:
Line 39:		Line 45:
	[[File:Packman-example.png\|200px]]		[[File:Packman-example.png\|200px]]

	If the package system is maintained well and device templates are created for most conceivable devices and confirmdependencies is used then entire package system could be much more tightly controlled, eliminating many errors and all around making things easier and more automatic from a user perspective.		If the package system is maintained well and device templates are created for most conceivable devices and confirmdependencies is used then entire package system could be much more tightly controlled, eliminating many errors and all around making things easier and more automatic from a user perspective. Note: The proposed package compatibility matching selections are not shown in the above graphics.

Phenigma at 05:27, 19 February 2013

2013-02-19T05:27:30Z

←Older revision		Revision as of 05:27, 19 February 2013
Line 27:		Line 27:
	*No change to existing behaviour, completely backwards compatible.		*No change to existing behaviour, completely backwards compatible.

	So, to illustrate my point, here is a before picture:		So, to illustrate my point, here is a before picture of the package source definitions:

	[[File:Packman-before-cleanup.png\|200px]]		[[File:Packman-before-cleanup.png\|200px]]

	And here is an after picture of what a completely cleaned up package ~~dependency~~ screen in webadmin could look like(if this was applied to previous releases, which it could be, by backporting a small change in ConfirmDependencies.cpp) [note the checkbox I refer to above is not shown here]:		And here is an after picture of what a completely cleaned up package source screen in webadmin could look like(if this was applied to previous releases, which it could be, by backporting a small change in ConfirmDependencies.cpp) [note the checkbox I refer to above is not shown here]:

	[[File:Packman-after-cleanup.png\|200px]]		[[File:Packman-after-cleanup.png\|200px]]

Phenigma: /* Background - Database/Package management system */

2013-02-19T04:45:32Z

Background - Database/Package management system

←Older revision		Revision as of 04:45, 19 February 2013
Line 5:		Line 5:
	The database stores:		The database stores:
	# a list of all packages that lmce requires for devices		# a list of all packages that lmce requires for devices
			# OS and Distro Compatibilities for each package
	# multiple sources (repositories) for each package.		# multiple sources (repositories) for each package.
	# multiple OS and/or Distro compatibilitees for each of those sources.		# multiple OS and/or Distro compatibilitees for each of those sources.
	Currently a new source must be defined each and everytime a new distro is released (intrepid, lucid, precise). This ~~creates~~ an extremely large and complicated system ~~for package management in the webadmin~~. The complexity makes it difficult for people to understand grasp the use of the management system.		Currently a new source must be defined each and everytime a new distro is released (intrepid, lucid, precise). A new package compatibility may also need to be defined. This is an extremely large and complicated system. The complexity makes it difficult for people to understand grasp the use of the management system.

	== Proposed Database/Package management changes ==		== Proposed Database/Package management changes ==

Phenigma: /* Proposed Database/Package management changes */

2013-02-18T21:02:24Z

Proposed Database/Package management changes

←Older revision		Revision as of 21:02, 18 February 2013
Line 15:		Line 15:
	**These systems are all different enough to warrant seperation.		**These systems are all different enough to warrant seperation.
	**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.		**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.
	**~~Repository~~ management becomes ~~much~~ simpler/easier		**RepositorySource management becomes simpler/easier
	**Packages for an ubuntu system would not ever attempt to be sourced from an alien (ex. raspbian) repository, unless explicitly defined as a compatibility.		**Packages for an ubuntu system would not ever attempt to be sourced from an alien (ex. raspbian) repository, unless explicitly defined as a compatibility.
	**Currently it is confusing for devs to determine if a repository could be unintentionally considered as an alternate source (ex. right now a raspbian repository could be considered as an alternative to an ubuntu repository, if a package is not found, because they are defined as the same OS [linux]).		**Currently it is confusing for devs to determine if a repository could be unintentionally considered as an alternate source (ex. right now a raspbian repository could be considered as an alternative to an ubuntu repository, if a package is not found, because they are defined as the same OS [linux]).

Phenigma: /* Proposed Database/Package management changes */

2013-02-18T21:01:59Z

Proposed Database/Package management changes

←Older revision		Revision as of 21:01, 18 February 2013
Line 14:		Line 14:
	**Currently all Linux based OSes are grouped as one OS.		**Currently all Linux based OSes are grouped as one OS.
	**These systems are all different enough to warrant seperation.		**These systems are all different enough to warrant seperation.
	**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.		**Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.
			**Repository management becomes much simpler/easier
	**Packages for an ubuntu system would not ever attempt to be sourced from an alien (ex. raspbian) repository, unless explicitly defined as a compatibility.		**Packages for an ubuntu system would not ever attempt to be sourced from an alien (ex. raspbian) repository, unless explicitly defined as a compatibility.
	**Currently it is confusing for devs to determine if a repository could be unintentionally considered as an alternate source (ex. right now a raspbian repository could be considered as an alternative to an ubuntu repository, if a package is not found, because they are defined as the same OS [linux]).		**Currently it is confusing for devs to determine if a repository could be unintentionally considered as an alternate source (ex. right now a raspbian repository could be considered as an alternative to an ubuntu repository, if a package is not found, because they are defined as the same OS [linux]).