Oliver Grawert schreef op 28-09-2016 13:29:

beyond this how do you know the bug is not caused by a (possibly)
patched libboost, a gtk patch mint applies, held back upgrades or some
weird filesystem mangling the mint installer does ... there are
millions of possibilities you can not take into account without deeply
knowing what mint does. it doesnt matter if it is a packaging problem
or not as long as there is a possibility of something non-standard in
the system causing it. if the mint support can nail it down with
evidence to be an ubuntu problem, then yes, there is no issue at all
with filing it on launchpad.

Intuition ;-).

Any root-owned-based-issues are not going to be related to libraries or GTK-issues.

I cannot attest to held-back upgrades because the command line "apt" system functions as I am used to from Ubuntu and even though my system is configured to not install kernel upgrades (from their GUI) I just saw a new kernel being installed through apt.

The latest version of LibreOffice was installed on that system on 11th of July. That's the current version. The system was installed on June, 28. As far as apt history tells me .. well it was caused by apt-upgrade, not synaptic, so it would have installed everything. It is a long list and I have no clue what updates would have been held back by the "safe" system.

But that covers the span of June 28 to July 11.

I consider it almost impossible that not upgrading the kernel since the ISO version of Sarah would have created any trouble. It was probably the first upgrade... the installer must have run the commands of june 28. apt-get --force-yes --yes upgrade, apt-get --force-yes --yes dist-upgrade, and then a long list of specified package on the command line 4 minutes later. Anyway.

June 28 was ISO install. July 11 was internet upgrade.

How likely that LibreOffice would not have worked if only it had been upgraded?

+ dependencies.

Further the likelyhood of Linux Mint pushing broken packages and holding back upgrades in something as predominant as LibreOffice and no one noticing until 2½ months later someone noticing is just...

The problems the user indicated were of the file-ownership kind and before a repository issue or a synaptic issue.

On a fresh Sarah install libreoffice is installed by default.

So either this is an older installation (and this is not a bug in the LibreOffice package) (not even against current Mint) or the person had installed LibreOffice before and mangled things up prior. I doubt that, but who knows. It seems to be an out of date system but at least it is clear from this that the current Mint does not suffer any such thing.

So that strengthens my conclusion that neither Ubuntu (packages) nor Mint (system) is to blame and indeed the person should report to Mint forums or something of the kind but the idea that this is a present day problem in Mint and would be caused by present day Mint alterations to the Ubuntu base system (if anything) is just not the conclusion of greatest likelihood here. Sarah upgrades from older versions of Mint suffer frequent problems and in general is completely disregarded as a viable path; the entire dist-upgrade feature for Mint causes even many more problems than it has on Ubuntu.

For this reason I simply wonder what kind of system the user has; even though possible, it is doubtful it is a fresh install of Sarah?

Regardless, the quick assumption that it must be something to do with Mint an sich and its alterations just doesn't seem very viable.

The only reason I was writing this is that I can understand your point of view (Mint goes to Mint first, this is a user support question and has nothing to do straight away with ubuntu-devel-discuss) but also that of the OP (if it is a package issue, it is not unfair to report it against ubuntu).

From my point of view it can be reconciled by saying:
- It is understandable to use the email address you see in the package; because where else can you turn to so rapidly, I don't think has a strong presence in direct (email) customer support, in that sense. - It is understandable that as a user you could or would have no clue as to what is causing this issue. - If it /were/ a proper package issue you would be welcome here but given everything we know this is just not likely. - I'm sorry, but even if you fall into a support gap because of this your place is at Mint - Perhaps the system needs better tools to directly query the experience of other people, such as being able to (automatically) report statistics on correct and incorrect installs, works for me doesn't work for me, etc.

Suppose we had a system of maybe 4 tiers of simple binary statements:

- installs / doesn't install
- runs / doesn't run (works / doesn't work)
- works well / doesn't work well (I can get it to work and it does as advertized)
- content / not content.

People never like giving information as a default operation, but only as a choice, I guess.

Regardless you could think of the first quality to be automatically determined.
The second quality could be a quick self-test of the package.
Only the 3rd and 4th are really user-choices.

They would be "functions for me" and "I like it".

Something like /installs/works/functions/like.

Then people could query the database on that package to see if there are any problems with it before they report it.

Ideally you have system information to go with it so it would be required to specify the source of the system in order to be able to use the system. It would be required to specify both distribution type/name (Ubuntu, derivate, Mint, something else) as well as state of the system (fresh install, upgrade from older version). It would just be a common task in a GUI system to process user-relevant packages. Libraries would be excluded and the user needs to choose to either automatically report them, report them as part of personal choice (each time) or not report them at all. Libraries then only report quality 1 and 2. Ideally you should be able to edit the list of what you report, because principally enough information is sent to identify your system (IP address). User programs that are relevant enough (such as those that require configuration (Samba, autofs) or meaningful to a user (as a recognisable entity you manually install) would be on the list of a task for the user to perform.

The GUI pops up a screen that is nothing but a vertical list with horizontally the 4 choices (and name of the package to the left). Or just two choices with the option to adjust the other two.

Crafting a PHP mockup in jQuery if you like (my GTK/Python knowledge is too abysmal at present).



in general though i was reacting to:

"The last time I tried to report a bug in this package, someone told me
I was in the wrong place. I am not sure how talking to the package
maintainers could be the wrong place!"
...
"Unless I am mistaken, you are the package maintainers, so it does not
matter what Linux system it is installed on, it should work, right?"

it *does* matter a lot and the way the mint developers picked to create
their distro plays a big role here.

Well yes but with the information we have we don't need to make a fundamental or principial or theoretical claim here, it is enough that you already know it is probably not an issue with the package and with the Mint system at all, so you don't even have etc come to the point where you have to make such fundamental statements such as would be the case if the problem were related to Mint or its deviations and you wouldn't be able to tell anymore what differences that would make. I'm just saying that is two steps further.

Step 1: user question or development question?
Step 2: recent system or something already broken?
Step 3: Mint or Debian or Ubuntu?

I understand that you would cut things short and save time; by answering step 3 and then throwing away steps 1 and 2 as irrelevant.

However the assumption that "surely it is a Mint issue" is unwarranted or "You can never know what alterations base Mint has made" and you can simply say: yes perhaps you would have been welcome here but today is not the day because we are answering step 1 and with the information we have it is extremely unlikely to be a package problem with Ubuntu; please report to Mint instead (and that should be enough).

Then you can also say: it is unlikely that Mint-wide this is going to be broken (but you don't really have to).

Then you can say: There are problems between Ubuntu and Mint and we can't guarantee operation of our packages, but unless you are working on a recent system and you are certain you are not the only one experiencing this and you are certain the Mint people haven't done anything strange or you can reproduce it on Ubuntu and you have consulted the Mint people we cannot do anything for you anyway because we would need Mint developer resources and we are not going to do that.

Basically I would say:

Step 1: differentiate between package issue and non-package issue
Step 2: differentiate between normal Mint and abnormal Mint
Step 3: differentiate between Mint and Debian and Ubuntu

It is enough that you say: we know of no problems with our package; we would have been told such things; it is unlikely your distribution would have distribution wide problems with the package; your distribution would have fixed it or told us; and furthermore we are not Mint and cannot solve Mint development problems.

If you follow through all of those steps you are welcome back.

When you are sure it is a development issue for Ubuntu.

It's just that the user has no way to find out this information quickly on his own and turns to the email address to find out, unfortunately (?).

But maybe it is fortunate if we get a better system as a result, I will go make my mockup :p.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reply via email to