Re: Ubuntu and its derivatives (Lubuntu, Xubuntu etc.) should really consider adding cross-distribution installation/upgrade feature in Ubiquity

[brendanperr...@gmail.com]

Yes people should back up their data anyway. Implementing this would be
quite complicated it seems to me.

On Mon, Feb 5, 2018 at 1:08 AM, Xen  wrote:

> Βασίλης Κατσαρέλιας schreef op 02-02-2018 17:08:
>
> Anyway, I just want Ubiquity to feature a cross-distribution
>> upgrade/transfer feature. (e.g. upgrade from Ubuntu 14.04 to Lubuntu 16.04,
>> upgrade from Kubuntu 16.04 to Xubuntu 17.10)
>>
>
> Honestly this is more a place for an on-system upgrade mechanism as it
> already exists, rather than something that would, I think, place undue
> burden on Ubiquity.
>
> I think as it stands Ubiquity would need work on dealing with failure
> cases more elegantly before you introduced something that would invite more
> failure cases.
>
> What Colin says is correct about not formatting your root partition,
> although it might not be so clear to a user, because it is a rather
> "smallish" choice somewhere.
>
> What Ralph says is also correct; backing up user data (The contents of
> your own home directory) can hardly be considered "awful" in the full light
> of things.
>
> So if anything, also speaking as an outsider, this would need to be
> improved in a "do-full-upgrade" tool however it would be near impossible to
> cater to all cross-variant upgrade situations.
>
> So Βασίλης, I hope you realize that you would get a huge matrix of what
> needs to change where, ie.
>
>Kubuntu 16.04Lubuntu 14.04
>
> Xubuntu 17.10X X
>
> And that it would need a lot of work to separate everything.
>
>
>
>
> Βασίλης, do you really think that making a backup of your /home/user
> directory is not a lot simpler?
>
> I think what you are suggesting would be a task not even a commercial
> entity, or a fully commercial vendor would be happy in undertaking.
>
> Although technically feasible, in practice it would involve _first
> changing to your desired flavour_ and THEN upgrading.
>
> Or vice versa, but not all at the same time.
>
> Then the problem becomes simple: how do we change an existing system to a
> different flavour?
>
> I am not sure this is supported, but "cross-distribution upgrade" is
> clearly not the first goal.
>
> If, on the other hand, you just want to reinstall your system, then
> Colin's suggestion would suffice, but it is not so clear the installer
> would do that.
>
> So I think that in practice the only real enhancement that would be
> quickly needed would be to structure Ubiquity such that this option is
> evident to users.
>
> As to your upgrade, Βασίλης, I am happy you got it done.
>
> Regards,
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/ubuntu-devel-discuss
>
-- 
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

Re: ubuntu-dock-gnome

[Nish Aravamudan]

On Mon, Feb 5, 2018 at 5:59 AM, J Fernyhough  wrote:
> On 5 February 2018 at 13:53, Ralf ranfyy  wrote:
>> It's better to do it the "Debian way":
>> $ apt source gnome-shell-extension-ubuntu-dock
>>
>> sudo not required. This way you get the original source + patches applied
>> (if any).
>
> Cool, plenty of ways to get the source depending on what you want to
> do with it, though any improvements/fixes/changes to the software
> (rather than the package) should probably go upstream first.
>
> If you want the Ubuntu-specific source I'll add another option based
> on the .dsc file on the package page,
>
> dget -u 
> http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-shell-extension-ubuntu-dock/gnome-shell-extension-ubuntu-dock_0.9.dsc
>
> :)

There is also `pull-lp-source` and `pull-debian-source`, which do not
require knowing the DSC url nor modifying your sources.list.

-Nish

-- 
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

Re: ubuntu-dock-gnome

[J Fernyhough]

On 5 February 2018 at 13:53, Ralf ranfyy  wrote:
> It's better to do it the "Debian way":
> $ apt source gnome-shell-extension-ubuntu-dock
>
> sudo not required. This way you get the original source + patches applied
> (if any).

Cool, plenty of ways to get the source depending on what you want to
do with it, though any improvements/fixes/changes to the software
(rather than the package) should probably go upstream first.

If you want the Ubuntu-specific source I'll add another option based
on the .dsc file on the package page,

dget -u 
http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-shell-extension-ubuntu-dock/gnome-shell-extension-ubuntu-dock_0.9.dsc

:)

J

-- 
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

Re: ubuntu-dock-gnome

[Ralf ranfyy]

J Fernyhough  schrieb am Mo., 5. Feb. 2018 um
12:06 Uhr:

> On 5 February 2018 at 03:07, Technical Clarity 
> wrote:
> > I'm looking for the code to participate and improve.
>
> The package page
> (https://packages.ubuntu.com/bionic/gnome-shell-extension-ubuntu-dock)
> links to the home page
> (https://github.com/micheleg/dash-to-dock/tree/ubuntu-dock).
>
> J
>
>
>
It's better to do it the "Debian way":
$ apt source gnome-shell-extension-ubuntu-dock

sudo not required. This way you get the original source + patches applied
(if any).
-- 
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

Re: ubuntu-dock-gnome

[J Fernyhough]

On 5 February 2018 at 03:07, Technical Clarity  wrote:
> I'm looking for the code to participate and improve.

The package page
(https://packages.ubuntu.com/bionic/gnome-shell-extension-ubuntu-dock)
links to the home page
(https://github.com/micheleg/dash-to-dock/tree/ubuntu-dock).

J

-- 
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

Re: Ubuntu Monthly Update Cadence Proposal

[Xen]

Bryan Quigley schreef op 02-02-2018 17:55:


Stability means: no changes in functionality.



Ah, this is the key point of my proposal.  Stability for my purposes
means predictability when changes in functionality will occur.


I understand, I was just meaning to say that there is no culture or 
policy that says "use older versions of libraries".


One of the reasons MS Windows has been stable for so long is that they 
basically use ancient libraries.


The system got released, installed, and the core library set was stable 
over a long period save for some "runtime" updates (VC++ 
redistributables and later .NET redistributables).


After that, any applications that wanted their own libraries had to 
install them themselves.


In Linux I believe there is a tendency to always use the latest and the 
greatest.


Part of that is logical but in practice many version dependencies are 
not really defined because developers forgot about them, when everything 
is upgraded together, no issues, if you upgrade stuff in isolation but 
according to Apt dependencies, stuff might break.


I am just saying that this rather makes your efforts a lot more 
difficult to actually attain.


But if you can limit your "components" to smaller, more important 
elements and leave the bulk to the traditional upgrade mechanism, then 
perhaps there is not so much an issue.



I did consider that parts of this proposal might be easier in snaps,
which would be a bit more like you describe.


I know.

I just wanted to say I guess that the limited ability of Apt to actually 
undo operations makes it a lot harder for users to deal with breakage, 
it appears a quite un-considered use-case in the Apt ecosystem 
(downgrade? Why?)


This in turn makes it more difficult to determine what an upgrade really 
means and what undoing an upgrade really means.


Ie. upgrading to a newer kernel is standard, undoing it is non-standard.

So if the goal is stability in the face of updates, then users would be 
a lot more forgiving of breakage if "undo" was an accessible operation.


I tried to limit to items that we could test for a 6 month period of 
time.


Yes in general it occurs to me that certain core components might have 
reduced dependency sets (like the kernel) although I am sure that 
particularly the graphics stack thinks differently about that.


Isn't your main goal to achieve clarity for kernel and mesa updates?

I mean, to give them more proper "handles" so that you can define an 
Ubuntu installation in terms of their installed "stacks".


Right now packages are just a huge swamp (not trying to diss anyone, it 
is just an unidentifiable whole) without clear sign posts.


Defining "groups" would make it easier to give version numbers to "core 
components" and make stuff like Mesa more of a familiar "part" of some 
Ubuntu computer.


For me in Kubuntu the only graphical way to know the Mesa version is to 
run KInfoCenter and go down into Graphics -> OpenGL; but for me Mesa is 
something I don't know about.


Whereas today it seems to become more and more important.

Particularly the updates for e.g. Xenial have been all about the Mesa 
version (and the Kernel).


Your goal is to make it visible to the user right?

This would imply that those monthly metas do not only indicate what 
they

upgrade, but also what they didn't upgrade.

The monthly metas then indicate the exact versions of all core 
components.


Then we have monthly releases, I specifically didn't want to do that.


Barring that, you could never easily downgrade.

However, I think you want to reorganize, temporally restructure, 
refactor as it were...


You want to redistribute in time when these updates happen.

It just has very little benefit if you can't also downgrade.

But what you're basically suggesting is let all of the other upgrades go 
on without issue and simply plan ahead for the bigger ones, coalesce 
them, announce them, give them a version number (milestone), and make it 
a public schedule.


If downgrading is not a necessity then it's only about changing the 
order of things right.


It's just a little more structural planning in the hopes that e.g. the 
kernel can be upgraded first, then the graphics stack a month later.


Then the structure can be published (not trying to condescend here) and 
people will be happy ;-).


But I don't see the big difference with announcing ahead of time when 
the hardware-enable-ment stacks will occur.


I also don't see the big difference between an LTS that has HWE updates.

What would this "rolling release" have extra over LTS + HWE?

--
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

Re: Ubuntu and its derivatives (Lubuntu, Xubuntu etc.) should really consider adding cross-distribution installation/upgrade feature in Ubiquity

[Xen]

Βασίλης Κατσαρέλιας schreef op 02-02-2018 17:08:

Anyway, I just want Ubiquity to feature a cross-distribution 
upgrade/transfer feature. (e.g. upgrade from Ubuntu 14.04 to Lubuntu 
16.04, upgrade from Kubuntu 16.04 to Xubuntu 17.10)


Honestly this is more a place for an on-system upgrade mechanism as it 
already exists, rather than something that would, I think, place undue 
burden on Ubiquity.


I think as it stands Ubiquity would need work on dealing with failure 
cases more elegantly before you introduced something that would invite 
more failure cases.


What Colin says is correct about not formatting your root partition, 
although it might not be so clear to a user, because it is a rather 
"smallish" choice somewhere.


What Ralph says is also correct; backing up user data (The contents of 
your own home directory) can hardly be considered "awful" in the full 
light of things.


So if anything, also speaking as an outsider, this would need to be 
improved in a "do-full-upgrade" tool however it would be near impossible 
to cater to all cross-variant upgrade situations.


So Βασίλης, I hope you realize that you would get a huge matrix of what 
needs to change where, ie.


   Kubuntu 16.04Lubuntu 14.04

Xubuntu 17.10X X

And that it would need a lot of work to separate everything.




Βασίλης, do you really think that making a backup of your /home/user 
directory is not a lot simpler?


I think what you are suggesting would be a task not even a commercial 
entity, or a fully commercial vendor would be happy in undertaking.


Although technically feasible, in practice it would involve _first 
changing to your desired flavour_ and THEN upgrading.


Or vice versa, but not all at the same time.

Then the problem becomes simple: how do we change an existing system to 
a different flavour?


I am not sure this is supported, but "cross-distribution upgrade" is 
clearly not the first goal.


If, on the other hand, you just want to reinstall your system, then 
Colin's suggestion would suffice, but it is not so clear the installer 
would do that.


So I think that in practice the only real enhancement that would be 
quickly needed would be to structure Ubiquity such that this option is 
evident to users.


As to your upgrade, Βασίλης, I am happy you got it done.

Regards,

--
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