summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/forum/chroot_issue_when_upgrading/comment_7_c682c5e99a1e9910771de0589d74657c._comment36
-rw-r--r--doc/forum/chroot_issue_when_upgrading/comment_8_d1c546c6f88035d40eca823d25d67e92._comment21
-rw-r--r--doc/todo/type_level_port_conflict_detection.mdwn25
3 files changed, 82 insertions, 0 deletions
diff --git a/doc/forum/chroot_issue_when_upgrading/comment_7_c682c5e99a1e9910771de0589d74657c._comment b/doc/forum/chroot_issue_when_upgrading/comment_7_c682c5e99a1e9910771de0589d74657c._comment
new file mode 100644
index 00000000..f39df6a1
--- /dev/null
+++ b/doc/forum/chroot_issue_when_upgrading/comment_7_c682c5e99a1e9910771de0589d74657c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="picca"
+ subject="comment 7"
+ date="2016-04-01T05:47:33Z"
+ content="""
+Hello Joey
+
+with 2.17.2 I get this. (there is nevertheless a progression in the right direction :p)
+
+ [2016-04-01 07:42:02 CEST] process done ExitSuccess
+ /srv/chroot/unstable-i386-sbuild has Operating System (Debian Unstable) \"i386\" ... ok
+ /srv/chroot/unstable-i386-sbuild noop property ... ok
+ /srv/chroot/unstable-i386-sbuild apt installed apt-transport-https ... ok
+ /srv/chroot/unstable-i386-sbuild standard sources.list ... ok
+ Hit:1 http://ftp2.fr.debian.org/debian unstable InRelease
+ Hit:2 http://mirrors.kernel.org/debian unstable InRelease
+ Reading package lists...
+ Reading package lists...
+ Building dependency tree...
+ Reading state information...
+ You might want to run 'apt-get -f install' to correct these.
+ The following packages have unmet dependencies:
+ g++-5 : Depends: gcc-5-base (= 5.3.1-7) but 5.3.1-8 is installed
+ gcc-5 : Depends: cpp-5 (= 5.3.1-7) but 5.3.1-8 is installed
+ Depends: gcc-5-base (= 5.3.1-7) but 5.3.1-8 is installed
+ libgcc-5-dev : Depends: gcc-5-base (= 5.3.1-7) but 5.3.1-8 is installed
+ libstdc++-5-dev : Depends: gcc-5-base (= 5.3.1-7) but 5.3.1-8 is installed
+ libstdc++6 : Depends: gcc-5-base (= 5.3.1-7) but 5.3.1-8 is installed
+ /srv/chroot/unstable-i386-sbuild apt update ... failed
+ /srv/chroot/unstable-i386-sbuild apt cache cleaned ... ok
+ mordor chroot /srv/chroot/unstable-i386-sbuild provisioned ... failed
+ mordor replace /etc/schroot/chroot.d/unstable-i386-sbuild ... failed
+
+so now the proposition is to run `apt -f install`
+So what is the right way to solve this (I hope) last issue during chroot upgrade?
+"""]]
diff --git a/doc/forum/chroot_issue_when_upgrading/comment_8_d1c546c6f88035d40eca823d25d67e92._comment b/doc/forum/chroot_issue_when_upgrading/comment_8_d1c546c6f88035d40eca823d25d67e92._comment
new file mode 100644
index 00000000..9792a624
--- /dev/null
+++ b/doc/forum/chroot_issue_when_upgrading/comment_8_d1c546c6f88035d40eca823d25d67e92._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-04-01T17:26:15Z"
+ content="""
+ -f, --fix-broken
+ Fix; attempt to correct a system with broken dependencies
+ in place. This option, when used with install/remove, can
+ omit any packages to permit APT to deduce a likely
+ solution. If packages are specified, these have to
+ completely correct the problem. The option is sometimes
+ necessary when running APT for the first time; APT itself
+ does not allow broken package dependencies to exist on a
+ system.
+
+So I don't see how you could get into this situation unless perhaps
+your debootstrap configuration gets into a broken dependency situation somehow.
+
+IIRC, apt-get -f install can decide to *remove* arbitrary packages as necessary
+to get to a sane dependency tree. So I'm very dubious about doing it by default.
+"""]]
diff --git a/doc/todo/type_level_port_conflict_detection.mdwn b/doc/todo/type_level_port_conflict_detection.mdwn
index 47d5f0cf..b89ad239 100644
--- a/doc/todo/type_level_port_conflict_detection.mdwn
+++ b/doc/todo/type_level_port_conflict_detection.mdwn
@@ -8,3 +8,28 @@ I have a `resourceconflict` branch that adds this in Propellor.Resources,
but it is not yet integrated into the Property types. --[[Joey]]
[[!tag user/joey]]
+
+> On `typed-os-requirements` branch, I have the UsingPort 80 singleton
+> implemented. As soon as I tried to apply it to some apache properties
+> though, I realized a problem -- If multiple apache vhosts are defined
+> each as its own property, then each of those properties can't have
+> UsingPort 80. Because the idea is to not allow combining 2 properties
+> that use the same pprt.
+>
+> Similarly, Apache.installed can't have UsingPort 80, because each of the
+> vhost properties requires that, and would inherit it.
+>
+> So, this could be used for non-vhost stuff, like simple web servers, tor
+> nodes, etc. But how to handle vhosts?
+>
+> Of course, there could be a single property that defines all of a host's
+> apache vhosts, and it could then have UsingPort 80. But that loses the
+> flexible composition of properties.
+>
+> I suppose we could include the server: `UsingPort 80 Apache`
+> (or `UsingPort 80 "apache"` to avoid needing a data type with all the
+> servers. Or even write it `"apache" '> 80`)
+> And allow combining properties that have the same server on the same
+> port. Don't allow combining `UsingPort 80 Apache` with `UsingPort 80 Ngnix`
+>
+> --[[Joey]]