partitioning packages

[Adys]

Since Salix Installer(s) uses either GParted or cfdisk (util-linux), I was wondering if there is any reason for Salix (and/or for Slackware) not to update those packages (and their respective dependencies).

The versions included in Salix 13.37 installer are GParted 0.8 and util-linux 2.19. The default repositories don't include updated versions of those packages. Maybe these packages are evaluated for update only with new Slackware / Salix (beta/RC) releases? I'd like to know if there is any reason not to update partitioning packages (I would also include GPT fdisk tools too in this general question).

TIA.

[Shador]

Didn't we just recently discuss this regarding boot-info-script? Do you see any changes that match the exceptions, which I mentioned there, for the policy of not upgrading packages in stable releases?

Sorry, but although discussions are welcome and necessary, repeated discussions are effectively the same like deadloops. They have no result, take up much ressources like time and are not considered good practice anyway. You're more than invited to bring up valid and concrete suggestions even more so if you can offer actual contributions. But please be concrete and to the point. Going in circles gets nobody anywhere.

[Adys]

I don't see any relation between that topic about BIS v0.61 and this question.

BIS is an informational script. If a user runs an older version of BIS, or if it fails for whichever reason, nothing would be broken. It would not be as useful, but that's it.

Here I am not even suggesting to update these packages. At least not yet. Partitioning is "bigger than any particular OS", in a certain way. A bad partition task could ruin more than one OS installation, as a second partition with a different OS for one example. So if there are reasons to keep using a specific version of a partitioning tool, that's something I'd like to know, independently of Salix, Slackware or whichever OS.

Of course ANY update means time dedicated and the possibility of new bugs or regressions. So? Sometimes the update is worth it. And users request and suggest updates all the time, for many different reasons (and users are not developers with the required knowledge to evaluate if an update is necessary or convenient). That's not related to my question, and I'm not sure if updating these packages is really necessary for a future next Salix installer.

Given the respective release dates of the OS and the packages, the current versions in use are not a surprise. It makes perfect sense.

But Salix is using GParted (and its dependencies) or cfdisk (util-linux). The packages have been released with updates during the last year several times, for several reasons. I am not suggesting to apply any update and to release new ISOs. I am just curious about if there is any special reason not to provide updated versions in either repositories. Meaning, if there is anything already known, besides the potential of some currently-unknown problem, or besides the evident lack of time reason. Or maybe it is about some dependency change?

I'll extend the question even further. If I happen to use an updated version of those tools (not from Salix), does anyone know about any potential problem / bug / conflict, that could make me (or anyone else for that matter) think I should use an older version, such as the ones in Salix repositories?

If I get no reply with info, then I will remain with this curiosity unresolved. No tragedy either. If someone knows something about this, I'm kindly asking to share it here.

TIA.

[mimosa]

My understanding is that it's the policy to stick with whatever versions Slackware itself has, except under certain circumstances as described by Shador. This conservative policy aims to ensure greater stability overall. It also saves weighing up the merits of each case, because according to the criteria in place, updating is only even considered under those well-defined circumstances. The overall process is thus objective and, on balance, likely to be robust. Salix follows Slackware in not setting out to be a bleeding-edge distro, for these reasons, as far as I understand it. That can seem perverse in particular cases, but the idea is presumably to avoid far more cases where things just break. Also, if you know what you are doing, you can make your own adjustments. The fact that that can be quite difficult and require a high level of knowledge (as these forums demonstrate) is a further indication of the soundness of the policy. The difficulty faced by users would correspond to extra work for the devs, were the policy to be less conservative, probably leading to a decline in the overall quality of the distro.

[Shador]

I certainly don't mind updating packages. The last weeks I could have easily spared some time for that. But unfortunately me like the other contributors needs to adhere to that policy too. And it's there for a good reason: not to pollute a finished, stable release with possible regressions.

Currently the problem is that Slackware development is going in a very slow pace. So the current release is terribly outdated and Salix has no base for a new release. I certainly don't like this myself. One machine of myself is lacking ANY kind of networking drivers with 2.6,37 and the pending package upgrades start piling up. But there's nothing we can do about that except hping and waiting.

For Slackware packages everythings more complicated. We won't diverge from the upstream version in that case without extraordinary reason because being based on Slackware is the fundamental idea with Salix. What's Coca Cola without Cola? A drug?
And believe me Pat, the guy behind Slackware, is more conservative than a republicans granny. But hey, we have to live with that and after all he's doing a really good job with Slackware (because of this?).

Finally you're saying yourself how critical partitioning software is. I think it's better to live with known flaws than unexpected disasters. We don't want to force 2012 upon you. But nobody can prevent you from doing it youself (with your own responsibility).

[Adys]

I do understand the philosophy behind Slackware and Salix. That's exactly why I am approaching Salix.

To be clear, I am not requesting to update the repositories. Moreover, if for some reason I would want to use updated partitioning tools, there are enough alternatives so that I wouldn't even need to think about building some updated package by myself .

I would say that my question was more about understanding how the Slackware / Salix philosophy would apply in practice to these type of (important) tools, specially when bug fixes might be crucial.

Let me put it this way. A few years ago, cfdisk (util-linux) was version < 2.19. At some point it was updated to v2.19 in Slackware. I am wondering what triggered that update (or any update of cfdisk in Slackware before that). For example, is it just the next beta cycle? Or, if it is something else, then what triggered that update, but not to have available the new updates to util-linux in the repositories of Slackware. After all, we are not talking about "some random package".

I don't want to get OT, but I’d like to give a different example so to illustrate the goal of my question. mkisofs of cdr-tools is currently in alpha development. Currently there is alpha 7 available, yet Slackware has alpha 2 available, and of course there is the (previous/current) stable version. Then, what triggered the availability of alpha 2, and why not to update to alpha 7 This OT example is very different from the OP, but it has in common, at least in part, the same kind of wondering behind the original questioning.

OTOH, if all this happens to be just about available time of one person only (which I'm not saying that's the case; I just don't know), then the real reasons are not just philosophy or stability .

I hope I am making more sense about the intention of these questions.

[thenktor]

I don't want to get OT, but I’d like to give a different example so to illustrate the goal of my question. mkisofs of cdr-tools is currently in alpha development. Currently there is alpha 7 available, yet Slackware has alpha 2 available, and of course there is the (previous/current) stable version. Then, what triggered the availability of alpha 2, and why not to update to alpha 7 This OT example is very different from the OP, but it has in common, at least in part, the same kind of wondering behind the original questioning.

No upgrades in the stable branch, unless there is a new version that fixes:
* a security hole
* severe bugs

An alpha7 is not necessarily better than an alpha2. The current branch is used to test this.

[Adys]

No upgrades in the stable branch, unless there is a new version that fixes:
* a security hole
* severe bugs

Well, I would think that sometimes there are new features that may be worth the update too.

But I understand the point. That's why I was intrigued about the partitioning packages not being updated.

Let's see, why a partitioning program would be updated by its devs? It could change dependencies. It could add new support features for filesystems that were not supported before. Or it could solve bugs.

From your answer, I get that there were no serious improvements (specially, bug fixing) in GParted nor util-linux that may be relevant to Slackware.

An alpha7 is not necessarily better than an alpha2. The current branch is used to test this.

Well, in theory, you are correct; alpha7 is not necessarily better than alpha2. I would hope that in practice in most cases 5 alpha steps would at least improve in something , but you are still correct as a general rule.

In any case, that still leaves the question; why on earth alpha2 would be included in the repositories (since it is just alpha), but not alpha7 (or any other alpha after alpha2)? Or, returning to the first examples, the need/reason cfdisk was updated from 2.18 to 2.19 a year ago, but not updated after that in Slackware repositories. It seems as if the reason was just that Slackware 13.37 was, by then, close to be released, and cfdisk 2.19 was just available, and nothing more. i mean, nothing special that would be so different from updating it now to 2.21.1 .

Again, I'm not requesting any specific version to be added to Salix repositories. I'm just trying to understand these type of cases.

[Shador]

no serious improvements

It's not a question of serious improvements. We don't care how upstream developers improve until the next development version. It's actually a matter of really serious existing issues, which are usually just security problems.

Well, I would think that sometimes there are new features that may be worth the update too.

A feature is never worth an update in a stable release. It's like when your on diet. It certainly seems tempting to have big cake with lots of cream and it's hard to say no to that cake. But when you actually do reject it you can be certain you won't gain weight, otherwise that's uncertain. Sometimes one needs to be consequent.

why on earth alpha2 would be included in the repositories (since it is just alpha)

Because something is better than nothing?

Truely stable - call them static if you want - releases are commonly used in IT and certainly have their benefits especially if you need stability. We don't want to a break a working system by throwing around updates which gives users no easy way to retain their system in a working but still up-to-date state. Unfortunately there is absolutely no way to estimate the impact of a change than by releasing it to a broad range of users testing it on their (live) systems. In case you don't care about that stability and prefer the very latest you're better of with a rolling release model like e.g. Arch Linux.


Finally I have to repeat myself that any input and discussion is welcome. But - the big but - we just can't justify every single small decision we're making in front of you. Even less if you start a discussion about each one. Sometimes you just have to accept the decisions others are making for you. I've always been willing to explain our reasoning to you and always took that chance. It's completely up to you whether you disagree and you're invited to tell us your opinion. And I always took the time to read and try to understand your view. Take it for granted that I respect your opinion and show this by spending time thinking about it. Nevertheless, it's impossible for us to have lengthy discussion with you all the time. This doesn't get better with your usually very long posts.
I've hinted this before: Our opinon, your opinion is fine. In the end we hopefully don't need to agree to disagree. But in the end, if we do, so shall it be. A then likely endless discussion ("deadloop") offers close to zero benefit since we already now your attitude although we don't CURRENTLY agree with it. But knowing about it gives us the possibility to respect it regarding future changes of our position.

[Adys]

@shador,

This topic is/was not about opinions, or (dis)agreeing with something. It is/was my attempt to understand, in practice, what causes a valid reason to ( request/suggest/ ) update a package in the repositories of Salix and/or Slackware.

Unfortunately for me, the general idea (serious bug fixes and the rest already mentioned) doesn't seem to match the practice. I hope to find it more clear / understandable in the future while gaining more experience (maybe when the next Slackware and Salix versions would eventually be released).

I would comment on some other paragraphs of your post, but I don't want to make a new long post that would not get us closer to the goal of the topic.

I do appreciate the time you all have taken to answer. Thank you.