Important fixes idea

Archived topics about LMDE 1 and LMDE 2
Locked
sobrus

Important fixes idea

Post by sobrus »

Hello :)

I've noticed that LMDE has problem with lack of known bug fixes. In normal rolling distro, you have things broken quite often but hopefully fixed quickly too.
Since LMDE is semi-rolling, it is more stable, but unfortunately also fixes can come rarely.

I just wonder if you could differentiate between 'updates' and 'fixes' and push such fixes from debian to lmde more quicky, before next UP arrives.
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.

To minimize additional LMDE team work, It could work in the following way:
- user report his/her problem AND known solution (=fixed package from debian repo) WITH links to get more information (only such detailed reports would be accepted)
- somebody from LMDE team just verifies that such bug was in fact fixed in debian, and it is in fact affecting users and update is pushed to LMDE repo
- no updates/new features allowed, only bugfixes
- just before UP release all fixes are merged with next UP to achieve best stability (if they aren't there already).

To make things more safe, such fixes could be pushed to 'romeo' or something similar, not main repo,

Example (in this case I'm the user who reports a bug):

In UP5, fglrx 12.6-point1 driver is broken. 32-bit apps are simply not working wth OpenGL under 64-bit lmde.

This is known upstream bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683853
And it has been fixed in 12.6-point2 and subsequent releases (resolved bugs - important bugs).
http://bugs.debian.org/cgi-bin/pkgrepor ... ble#_4_3_5

Of course I understand that you don't want to push sid package to LMDE so:
- it could be restricted to testing repo only
- package could be put on "waiting list" and pushed as soon as it reaches testing.
- package could be pushed from sid only if bug is severe, it doesn't require any other updates/dependencies from sid, and works with testing without modifications

What do you think about it? Would it be very hard to maintain? Im talking just about known bug fixes.
No "i want new libreoffice!!!" or "it doesn't work and I dunno why!" complains would be accepted.

I think something should be done with bugfixes, because LMDE is not as stable as Ubuntu based version, yet it receives almost no updates.
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
zerozero

Re: Important fixes idea

Post by zerozero »

at the moment just subscribing and watching the community feedback.
naughty_bit

Re: Important fixes idea

Post by naughty_bit »

I'm definitely interested to have more updates coming our way. I think that UP should be confined to mint packages, like cinnamon, mate, etc. but not on debian internals. Those should be pushed more often.
And I would like more up to date libreoffice, firefox, thunderbird. There were several security fixes and no updates were pushed yet.
escolar

Re: Important fixes idea

Post by escolar »

I think UP is a good system to balance stability and newness. But, probably the incoming repositories had to be updated from Debian incoming in a more regular basis, so testing smaller updates will be easier and UP more frequents.
Monsta
Level 10
Level 10
Posts: 3071
Joined: Fri Aug 19, 2011 3:46 am

Re: Important fixes idea

Post by Monsta »

sobrus wrote:I just wonder if you could differentiate between 'updates' and 'fixes' and push such fixes from debian to lmde more quicky, before next UP arrives.
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.
Yeah, it would be very nice. Such fixes would quickly solve some annoying problems like:
Now about what would make it harder for the Mint team. Packages tend to have dependencies, and some update (even if we think of it as just a bugfix) may pull additional updates for some other packages. This would require an additional testing afterwards.

Also, such a bugfix update may be considered as a partial upgrade. When a new Update Pack is released, it's necessary to make sure there are no upgrade issues for both the users who have any bugfixes installed and the users who haven't any.
odo5435

Re: Important fixes idea

Post by odo5435 »

I'm a Mint/Linux newbie overall and know next to nothing about LMDE in particular (I do run it on an ASUS EeePc which performed flawlessly during a serious flogging on a recent overseas trip) BUT, the reason I was attracted to LMDE in the first place was the idea of never having to do 'fresh' installs.

UPs are a move in the right direction. The major concern for me is not the size of the downloads required after each release. It's the time they take to download (four hours for me for UP5). Additionally, in the case of UP5 it required me to sit in front of the screen and make decisions to keep or change the existing structure and also to ensure GRUB was correctly placed.

In reality, it would have been quicker to do a complete 'fresh' reinstall.

There seems to be a dividing fence here between those who are happy to wait for the complete package and those who would prefer that Mint somehow separate its own changes from those generated by Debian in general. It's just my uninformed non-programmer/developer opinion, of course, but sending through incremental, non-Mint fixes as they occur (provided they don't impact on Mintification) just makes common sense,

And if it makes the whole process quicker and somehow doesn't require me to sit in front of the monitor for several hours, I'd be a very, very much happier user (my wife would thank you too).
sobrus

Re: Important fixes idea

Post by sobrus »

Download size can be a problem, yes. But on the other side, you have to do it only once a few months - it is not that bad anyway.
Rolling distros always require fast internet connection. It is how they work. On opensuse tumbleweed you can have something like 300MB updates DAILY.
LMDE is semi rolling, so you have few months of peace after update. This has advantages - and disadvantages of course.

For example - I believe your EeePC has SSD drive. If updates were much frequent, drive wear would be higher. And who needs new libreoffice every week anyway?

Reinstalling is faster if, and only if, your system is 'out-of-the-box' or close to this state.
Once you custiomize your OS, change /etc, write your own scripts, compile own programs - it will be *real* pain. Doing this can take hours, doing it all over again drives crazy. And you will always forget about something.
Rolling distro really helps, I came here from suse and I really hope reinstalling won't be neccesary until I buy new machine.

Questions can be annoying, that's true. But please remember LMDE is not quite "newbie oriented". Your wife would be probably happier with Ubuntu based Mint Main LTS edition.

btw. update is slow mainly because apt-get is slow. Even on SSD. That's why apt-get isn't used during fresh install at all. It's something like cheating - on fresh install files are just copied off dvd rather than istalled from packages.
opensuse's zypper is MUCH faster in this regard, so I think debian package management is to blame.
jjaythomas

Re: Important fixes idea

Post by jjaythomas »

sobrus wrote:I just wonder if you could differentiate between 'updates' and 'fixes' and push such fixes from debian to lmde more quicky, before next UP arrives.
This wouln't probably make any sense if UP was relased every month, but since it is released not as often, this can be a good idea.
There is usually no problem with living few months with old program version, but it's harder to live with annoying bug.

Ditto and maybe a way for apps from backports (many times there really bug-fixed versions) to get thru.

I would think the 'update (debian) manager would need to change, and a new tag (or existing :?: ) would need to be incorporated some how to automate.

J.Jay

P.S. I would (other may not :( ) forgo a Upack (or 2) if need extra time (cause size of team ect.) to incorporate something like that. In long run think that would simplify UPack sys (less things to test in Upacks itself) :idea:
Locked

Return to “LMDE Archive”