My branch pin of repo https://git.spwhitton.name/propellor adds
Apt.suiteAvailablePinnedApt.pinnedToFile.containsBlock- a haddock for
File.containsLines
There is one TODO in a comment that relates to propellor's algebraic data types. I'd be grateful for help with that. --spwhitton
I wonder if it would be better to separate
suiteAvailablePinnedintosuiteAvailableandsuitePinned? The latter could require the former.pinnedToshould probably be DebianLike not UnixLike. And its[String]parameter ought to be[Package].Is
File.containsBlocknecessary? Seems that if you care about ordering of blocks in the file, you generally should useFile.hasContentto specify the full content. Rather than using /etc/apt/preferences.d/10propellor.pref for multiple properties, you could use a separate file for eachpinnedTo'with the parameters encoded in the filename.As to the TODO, I tried adding this:
And the compiler tells me it's wrong because
updateis not revertable. But of course, there's no need to revert apt-get update, so this compiles:Cleaning it up left an an exersise for the reader. Might be possible to combine
robustlyandrobustly'into a single function, but I'm not able to see how immediately.However.. Seems to me that whatever you wanted to use
robustlywith to spur that TODO, you could just apply it to the first Property of the RevertableProperty, and not to the second one?Thank you for your feedback, Joey.
I see how this could be useful, in particular if you want to make a suite like Debian experimental available, which won't cause any packages to be automatically upgraded.
However, it makes it less convenient, and perhaps dangerous, to revert a pinned suite. For example, suppose on my Debian testing system I have
Apt.suitePinned Unstable 100. If I revert this property, it will remove the pin but not remove the source. Then my system might get mass-upgraded to sid if I'm not careful.We couldn't have the revert of
Apt.suitePinnedremove the source because then if I have both& Apt.suiteAvailable Unstableand! Apt.suitePinned Unstable 100, the second property would cancel out the first, which doesn't make sense.On balance, I think it's best to keep the current property. A property adding sources to apt.sources.d should probably force the user to pick a pin value, to avoid any unexpected upgrades.
This was my 'TODO'. (Since the property takes a
DebianSuite, I think it should beDebiannotDebianLike.)I tried applying
tightenTargetstopinnedTo, but that only seems to affect one half of the revertable property. Do I need to implement a new tightening function?I don't think so. The parameter to
pinnedTocan be a wildcard expression or a regex (perapt_preferences(5)). Neither of these are accepted by other existing properties that take[Package], such asApt.installed. I could add a new type alias, if you prefer.This was what I tried on my first attempt, but it gets very complicated if the user passes a wildcard expression or a regex instead of a package name. I would need to convert that wildcard expression or regex to a cross-platform filename, and the conversion would need to be isomorphic to avoid any clashes. The
File.containsBlockseems more sane than that.I don't understand how
robustlyis relevant to my TODO -- please see above.That example with reverting one property overriding another property is a general problem propellor has with conflicting properties. Normally I don't much worry about it, but I agree an accidental mass upgrade is a good reason to avoid that problem here.
Yes please add a new type alias for String (or an ADT) if Package is not appropriate.
I had misunderstood which function the TODO was for..
Nice surprise that tightenTargets works on RevertableProperty at all. Since it does, you should be able to tighten one side, revert, tighten the other side, and re-revert. Or, deconstruct the RevertableProperty, tighten both sides individually, and reconstruct it.
I've added a Propellor.Property.File.configFileName that should be suitable for your purposes, and others..
Propellor won't be parsing any of the regexp or globs, so I've added a new type alias rather than an ADT.
I don't understand what you're getting at with the first of these suggestions.
In any case, now that I'm not using
File.containsBlock, it's easy to just applytightenTargetsto each side.Very nice
I've updated my branch to use this. I haven't removed
File.containsBlock, since it might be useful in the future, but you could of course revert the relevant commit.