remove choice of using aptitude instead of apt [dep #183]

i have removed the ability for users to specify aptitude options as part of this. i've not bothered to try to automatically translate aptitude options to apt options for backwards compatibility since this would be rather difficult and messy. users using --aptitude-options will just have to adjust to --apt-options themselves.

Sorry, but this is a NACK from me - I'm not entirely convinced on removing aptitude, as some users like it without any specific reason - but if it's removed, then backward compatibility needs to be kept in my opinion, and this translation needs to be done. Not breaking existing use cases is more important than internal tidyness for a public project.

Yeah I completely understand the hesitation to take the choice away from users, considering that in theory they could have specific options set for it via --aptitude-options which they may not have duplicated necessarily in --apt-options, but I'm not sure that it's likely, and there are places in the code that specifically use apt-get which would encourage specifying the options for both...

The change is inspired by having come across Daniel's fork of live-build, which made the same change to rip this out, and provided the explanation for why it was introduced in the first place. Though of course our live-build has a wider userbase.

Trying to maintain backwards compatibility for translating --aptitude-options to --apt-options seems like a nightmare of a hack to me... I'd probably lean towards leaving the options in, perhaps with a warning to discourage its use to clear the way to future removal, than attempt attempt such translation. :/

I am +0 personally.

I'm not to worried about breaking user configuration, I doubt that many people opted to use aptitude but I can understand the fear. Trying to keep backwards compat is a no-go as it would be even more complicated than just keeping the current feature.

Bug given Luca's nack, I think we should close this MR.

Also I'm a bit puzzled by your priorities. You keep submitting new changes while you already broke other stuff that are still not cleanly fixed (cf !181 (closed))

Is there an end to this stream of merge request? Do you have actual features to contribute instead of only refactoring and cleanups?

I'm happy for this one to be closed if that's what you'd like.

I updated #181 with the completed fix earlier today, tackling it having been my first priority, I just added a comment rather than re-write the MR summary. I did not mean to cause confusion with it.

The next big priority for today is to address the syslinux layout issue raised yesterday which I was going to get on with shortly. The #181 issue distracted me from that yesterday. I don't think there's anything else otherwise that I've broken to fix is there?

Some things like this I'm just pushing from stuff already sat waiting to go.

I have a set of notes in a file, concerning various bugs, bullet proofing, feature enhancements, and such, some of which I've done some work one, some not. We've gotten through most of the old 2015 work, the big item of #718225 being the most significant thing left.

I've been considering whether you might like me to perhaps try to put together some sort of summary of the major items to give you some idea of where I'm heading with things.

In some ways, so much as you allow me and seem happy to go along with, I'm trying from the restricted position I'm in with the project, to push ahead with development of it. With everything going through yourself there is both a significant positive - a second eye to notice issues and discuss changes (though this could take place anyway) - and a big negative - eating up your time - but trust needs to develop of course if you were to ever consider granting me developer status, and although I'd hope you see some value in what I'm accomplishing, I'm thus far afraid of rejection to ask for such.

I would definitely like some visibility on where you are headed. Send a mail to debian-live@lists.debian.org and put me in copy? (I'm not reading the list closely)

I can understand your desire to not be "restricted" but at the same time you must understand that live-build is an important piece of software that we want to keep working without introducing backwards incompatible changes.

And your style of development, the rate of change that you are following, the obvious mistakes that I have seen during review, is not giving me the confidence to grant you direct commit rights. Slow down, review your own code, write commit messages that speak for themselves even for small changes, rebase your branches so that fixups are squashed in the original commit where you introduced the mistake, etc. That's the kind of change that I would like to see on your end.

Ok, I'll try to put together the email a little later.

I absolutely appreciate the importance of live-build and keeping existing usage working, including that it has business use not just personal use. I would not want you to think that I'm just throwing change about recklessly. This particular change for instance was not submitted out of reckless disregard for backwards compatibility, but it was a quick thing to throw together and propose for your consideration of how much concern you felt regarding this particular feature.

I was expecting that if you were at some point to consider direct access, that at least for the short term, this would consist only of permission to direct push the more minor of things, doc fixes, typo fixes, and such, with the rest going via MRs for you/Luca to approve as currently.

I completely appreciate what you've said in your last paragraph. There some aspects of my work here that are not typical of me though. I do typically throw myself at things putting in a lot of effort, but I'm usually something of a perfectionist believe it or not. I usually very carefully review and review and review in detail the changes I'm making to avoid mistakes, and then further routinely review what's been merged subsequently to double and triple check things; I am trying to take care here, but for one reason or another a bunch of silly mistakes including numerous silly commit typos I'd not usually make are slipping past my notice thus far. This is in no way typical of me, it's causing a little embarrassment, and has been making me question myself whether I need to slow down a little or something to restore my usual level of quality. I understand it not inspiring sufficient confidence. I have no intention of causing the next release to end up broken from my work. Since we've gotten through the bulk of what I'd gotten prepared, perhaps things will slow down a little moving forwards anyway. Wrt. fixups I am doing this as I work, but I've tried to avoid it in places with fixing a mistake in an already submitted patchset to avoid making chaos for review, but I can do that more if preferred.

I was expecting that if you were at some point to consider direct access, that at least for the short term, this would consist only of permission to direct push the more minor of things, doc fixes, typo fixes, and such, with the rest going via MRs for you/Luca to approve as currently.

That's something that I could live with for a start. @bluca what do you think?

Sounds fine to me too

Ok, done.

Thank you :)

I promise to not to abuse it and to limit direct pushes to what was suggested.

I almost finished the work overview yesterday, but became very tired. So far today I've been very busy dealing with other things. It'll be with you very soon.

added 3 commits

879a9c54 - config: tidy config files
58e0efed - config: tidy directory construction and empty directory cleaning
a4eaad72 - remove choice of using aptitude instead of apt

Compare with previous version

changed title from remove choice of using aptitude instead of apt to remove choice of using aptitude instead of apt [dep #183]

changed the description

rebased on top of #183, rather than #183 being based upon this, to avoid blocking #183

Closing the MR given @bluca's NACK of the MR.

closed

remove choice of using aptitude instead of apt [dep #183]

Merge request reports

Activity