Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get rid of the multiarch symlink #1224

Closed
wants to merge 2 commits into from

Conversation

@wdlkmpx
Copy link
Contributor

commented Jul 7, 2018

No description provided.

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2018

This is a pull request and an issue at the same time.

This looks like small change - and it is, thanks to important changes in 2createpackages and packages-templates.. i built a dpup, installed and compiled a few apps.. no issues so far.

But this change probably breaks all existing installations and alternatives to petget that also implement the symlink. Apparently some people also added the symlink to some sfs's and pet pkgs..

For deb-based pups: many package templates no longer apply 'their logic' to the pkg.. many pkg templates basically are there to create symlinks for older libs... some old apps may no longer run, the upups have many old apps from the 'common' repo.

But this is more a call for a discussion.. is it morally, politically, spiritually wrong to get rid of the multiarch symlink after so many years?

@peabee

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2018

I don't think I know what "the multiarch symlink" is..... sorry! Can you say what it is and what are the consequences of removing it? And why do you want to remove it? Is it causing problems? If so, where have they been reported?

"the upups have many old apps" - is this necessarily a bad thing? If the apps work and there is no need to update them they can still be used?

"this change probably breaks all existing installations" - this sounds bad!

At the moment, not understanding, I vote to not do this change - unless you can say why it is needed.

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2018

The multiarch symlink, also known as the 'multiarch hack' or the 'hack for multiarch' is a hack to alter the compat distro directory structure replacing the multiarch directory with a circular symlink to avoid breaking stuff.

  • /lib/i386-linux-gnu
  • /usr/lib/i386-linux-gnu
  • /usr/include/i386-linux-gnu
    etc

These are actual directories with many subdirectories.

2createpackages is faster and even the system seems to boot and work faster (might be the placebo effect)

In the past this was not feasable because 2createpackages and packages-templates created a bunch of broken packages because of the design itself. It's been an insane amount of work to revert or delete most of the poisonous stuff to get basic things to work. And this is just the tip of the iceberg.

@peabee

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2018

Still not sure what problem you are trying to fix - and for such a fundamental and disruptive change it must be a BIG problem to justify......I haven't seen any such problem reports.....
"And this is just the tip of the iceberg." is worrying.....

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2018

@peabee

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2018

UpupBB has no components coming from -puppy-common-
I venture to suggest that package-templates is not the place to be creating symlinks to satisfy old lib requirements - these should be created in EXTRA_COMMANDS= in _00build.conf as they are specific to whats included in a particular build
Some way of letting builders know what the dependencies are would of course be useful.

I still vote against "get rid of the multiarch symlink" as it is of limited benefit for the amount of disruption it might cause; puppy has existed for a long time with it in place without any major problem emerging; and everybody knows this is the puppy model and lives with it.

Would be nice to hear from others though.....

@woodenshoe-wi

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2018

Would be nice to hear from others though.....

I'm not going to vote for or against the changes, but if you were wondering what problems the changes were trying to fix here are two links.

#1043 (comment)
#822

The problems have already been fixed in other ways, but I guess they got some people (including 01micko) thinking that the symlink was causing more problems than it was fixing.

Theoretically as long as the multiarch directories are listed in /etc/ld.so.conf everything should keep working, but without testing you can't be sure.

I guess that is the reason that at least two branches are needed in woof-CE, one to build test builds and another to build stable releases.

If problems show up maybe the changes aren't worth it, but you can't know what the problems are without testing.

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Jul 10, 2018

This looks like a major change, a bit disruptive. The current changes in testing do need some testing and feedback.

It's just doesn't get any better than using git and a platform like github to make everything possible and easy to test and provide feedback. It's easy to spot issues, mistakes and meaningless changes.

For example the first changed line in 422e17d is completely meaningless, what does that mean?.. well it means that i was trying to do something but didn't get around to actually do it, or that the file is not that latest revision.

Hmm i don't know if this change made it possible.. but for the 1st time i'm seeing pup-volume-monitor work with the compat distro glib in a deb-based pup. I don't know if it's a glib update/fix.. hmm... what can it be.. i remember fixing warnings and stuff but i think it wasn't enough to make p-v-m work in a deb-based pups.

I removed the pet pkg and built a new dpup iso just to make sure, and... it's true, it's working fine.

@wdlkmpx wdlkmpx force-pushed the wdlkmpx:temp branch from fe434f2 to bb2776e Jul 15, 2018

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Jul 15, 2018

I updated all the relevant FIXUPHACKS, also removed the hack for slacko64 from merge2out and 0setup. In other words, this PR is ready to be merged, but we'll discuss this the next month (maybe).

The DISTRO_VERSION doesn't really say much about the actual woof version, so maybe it's time to add a new variable... W_VERSION. In fact major changes happen and DISTRO_VERSION rarely changes... i just want something i can use and be confortable with.. so what do people think about adding a new variable with the actual woof version.....

All these changes are not major changes for me though, these are the basic changes to get basic stuff to work, the amount of work to accomplish this is certainly irrational... it's undoing somebody's hard work what actually makes the project progress.

This will be merged after the testing branch is merged to master, i'm not going to test every puppy... people might want to comment about any important issues they find in the slackos or the upups.

@wdlkmpx wdlkmpx force-pushed the wdlkmpx:temp branch from bb2776e to 80d3874 Sep 4, 2018

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2018

  • This is something that should be announced in the blog and on the forum

I posted patches for puppy-get and Pkg (on the forum), i guess that's enough. I'm not aware of other petget/PPM alternatives. Whether my patches are ignored is not my business... woofce is just one of several forks

The more this is delayed, the more innocent souls will perish in the abyss of distant memory.. and it's already done and my time already wasted

After the pr is merged i'm willing to test and try to fix issues in isos provided by anybody as long as there's an accurate bug report, however fixes may happen on weekends..

  • In this pr i explained what the issue is about, so you can reuse my words or you should probably use your own wording and add this:

DISCLAIMER: You’re not getting anything. You understand? Nothing. You’re getting nothing.

@wdlkmpx wdlkmpx referenced this pull request Sep 18, 2018

@wdlkmpx wdlkmpx force-pushed the wdlkmpx:temp branch 2 times, most recently from 4f408a6 to 209d477 Oct 23, 2018

@wdlkmpx wdlkmpx force-pushed the wdlkmpx:temp branch from 209d477 to 98c11ca Nov 18, 2018

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2018

This is the final version of the pr. I noticed github has been improving a lot lately, you can see details that were not available before

@wdlkmpx wdlkmpx force-pushed the wdlkmpx:temp branch from 98c11ca to c99f1f7 Nov 18, 2018

@wdlkmpx wdlkmpx force-pushed the wdlkmpx:temp branch from c99f1f7 to 83060da Nov 18, 2018

@wdlkmpx wdlkmpx referenced this pull request Jan 28, 2019
@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2019

Last time i tested this, it was all working "right". But that was only in dpup stretch.

By merging this some work must be done to fix new issues.. ain't it fun.

It's been almost a year since i opened the pull request.

Now that puppy 8 has been released without any sort of coordination, would it be ok to merge this, maybe next month?

The master branch is up-to-date, only the testing branch would continue for a while. Basically some of the changes i have in mind introduce incompatibilities

So, should this be merged? Should i force my way? Should the deb-based pups be retired if this this is not merged? Should

@peabee

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

This change should be done in a separate branch - but we then need builds to be made from that branch and isos issued so that testing can be done and impact of "incompatibilities" assessed.
If the impact is that many existing pets become unusable then we are talking about starting a complete new repo which only contains pets that are compatible with this new architecture - that sounds like a very big job?
Retiring deb-based pups would be detrimental to Puppy.
I don't think you should force your way on this - some strategy is needed to progress slowly and carefully.
We seem to be living fairly successfully with the current architecture - are the benefits of doing a disruptive change so big that we want to face the disruption? I currently vote "No".

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 5, 2019

I created the experimental branch, an unstable branch where things may be discarded and forced updates may happen

This change is already there

https://github.com/puppylinux-woof-CE/woof-CE/commits/experimental

This is a disrupting change because it simply does not force a certain directory layout. All the changes in packages-templates are a prelude to this simple and disrupting change.

Hundreds of files were deleted so that this simple change can happen.

Imagine /usr/lib64 is a symlink to /usr/lib in slacko.. shouldn't it be fixed?

@peabee

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

So what do you now want to happen? Presumably a 64-bit Ubuntu or Debian build? As my only Woof-CE 64-bit builds are Slackware based presumably these wouldn't help test?? And we don't have any recent Debian 64-bit builds (I think...) so looks like it's @mrfricks BionicPup64 that has to be the guinea pig??

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 5, 2019

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 5, 2019

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2019

@peabee

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2019

pupsave upgrades will be way more problematic

If you are able to describe why this will be, I for one would find that useful.....
How will we go about testing this???

@peabee

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2019

First trial build of UPupDD-19.04 with EXPERIMENTAL.......
Good news - it boots ;-)
BUT
LOTS of build problems to fix because legacy links created both in zz_fix pets and in _00build.conf EXTRA_COMMANDS are now wrong

@peabee

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2019

Here you go.....
experimental iso
Now what should happen??

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2019

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2019

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2019

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented Apr 8, 2019

@wdlkmpx

This comment has been minimized.

Copy link
Contributor Author

commented May 8, 2019

This can be considered "merged" if we assume that the experimental branch is indeed the future of this project..

@wdlkmpx wdlkmpx closed this May 8, 2019

@wdlkmpx wdlkmpx deleted the wdlkmpx:temp branch May 8, 2019

@jamesbond3142

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

In woof-next, rootfs-skeleton is copied after all the packages have been processed, it overrides files and configs from the compat distro.. requiring less hacks.

Basically the hacks are all done in one place: rootfs-skeleton. Instead of spread over everywhere. So it's simpler to manage and maintain. You may still need distro-specific hacks though.

I never do pupsave upgrades, but after upgrades issues with the symlink and the ppm may arise.

We don't do upgrades Fatdog. It's too hard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.