Retire tahrpup?

[wdlkmpx]

Ubuntu has archived ubuntu trusty.

Now the compat repos urls need some fixing, but i think it would be ok to delete tahrpup ..

[mavrothal]

TahrPup is still a very popular puppy. Pointing the repos to the right place is needed rather than deleting it. If it is not generating any troubles for the current puppies (does it?) I would rather see it staying. With the new 'I'll be a puppy builder" enthusiasm who knows what they'll want to build. BTW should people in the forum be notified about the "experimental" branch and its association with the, currently popular, "woof-next" branch or it would be too much noise?

[jamesbond3142]

TahrPup is still a very popular puppy. Pointing the repos to the right place is needed rather than deleting it.

It's archive.ubuntu.com. I tried woof-next using with trusty previously and failed, so I thought the repo is gone. But later one I managed to do it, and found out that woof-next was even already setup to do it, so perhaps it was just bad network connection at the time of my first try.

BTW should people in the forum be notified about the "experimental" branch and its association with the, currently popular, "woof-next" branch or it would be too much noise?

I considered announcing it; that woof-next integration is in progress but then I thought I'd hear from @wdlkmpx first.

[mavrothal]

I considered announcing it

The fact is that there are several forum members that have develop a dislike for woof-ce for whatever, mostly irrelevant and personal, reasons. They are OK with you offering “a 5year-dead project” and can not complain when the real issues appear, but if they are offered an active project, all they’ll do is complain as they always did, because they are not really capable to address any issue. I believe that remotely serious builders have visited github and seen the activity and discussions.

On a different matter (should probably be a different issue), chrooted slackware builds may be easer for the user but for the debian family a puppy repo is needed if dpkg/apt/apt-get/synaptic is going to be used. Without it it maybe OK for building but for the user will be a mess if dpkg/apt is not aware of puppy files and the wild pets scattered all over the forum. If puppy is going to be utilising several distro-specific and native package managers simultaneously, may become a support nightmare. But I guess is probably a bit early to worry about these

[jamesbond3142]

The fact is that there are several forum members that have develop a dislike for woof-ce for whatever, mostly irrelevant and personal, reasons.

We can't tell them to like Woof-CE. But the question is, what is the alternative? (and that's the reason why I started that thread (the one in the "Misc" section). Turns out that at this point in time, really there is no other choice. DebianDog build system comes close but it can only builds from Debian.

They are OK with you offering “a 5year-dead project” and can not complain when the real issues appear, but if they are offered an active project, all they’ll do is complain as they always did, because they are not really capable to address any issue.

Well, your favourite character has thrown the towel off on that 5year-dead-project :smile:

I believe that remotely serious builders have visited github and seen the activity and discussions.

Agreed. There is a certain level of skills involved when you want to build a distro. Ability to use distro =/= ability to build one.

On a different matter (should probably be a different issue), chrooted slackware builds may be easer for the user but for the debian family a puppy repo is needed if dpkg/apt/apt-get/synaptic is going to be used.

Default slackware repo is pretty limited, but from what I've heard, salix repo is quite populated. Not sure how up-to-date it is, though.

Without it it maybe OK for building but for the user will be a mess if dpkg/apt is not aware of puppy files and the wild pets scattered all over the forum. If puppy is going to be utilising several distro-specific and native package managers simultaneously, may become a support nightmare.

Agreed. This is a mess. We may want to use packages from many distros, but there should only be ONE package management.

"Pkg" for example can install .debs, .txz, but my impression is (please correct me if I'm wrong) it will convert those foreign packages into its own internal format, and keeps a record of installed packages its own way. This is okay.

But if you try to have both PPM and apt-get active (for example), then all you get is incurable headache.

But I guess is probably a bit early to worry about these

No need to worry. But it's good to plan ahead.

cheers!

[mavrothal]

But if you try to have both PPM and apt-get active (for example), then all you get is incurable headache.

No doubt about it. The proper thing would be to make puppy scripts and apps proper deb packages with all the goodies (requires, suggests, replaces etc ) or slack packages or Fatdog packages ( 😈 ) or... but this is going to be even more work and will need a constant eye on what apt-get will be pulling after every update and how this is going to mess up the system. Hmmm... I think that the core of the problem is that puppy (and friends) is not designed to work as a normal rolling/updatable OS but rather as an immutable system with some occasional user additions. Oh well, let's see how the first build will fare in the wild.

[wdlkmpx]

Someone should fix tahrpup then.

Rename tahrpupfix.pet to tahrpupfix-1.pet and so on, test packages, etc and reupload fixed versions with a different name. The only thing i can do is delete.

There's no need to announce anything, i'm completely indifferent to the situation.

After commit https://github.com/puppylinux-woof-CE/woof-CE/commit/ef9a583bf66365ea7842c6f93ca6d4dd3607052c building a tahrpup is completely automated with ./build.sh, except that in 3builddistro you'll be asked to download and choose a kernel, so it's easy to build and test a tahrpup..

[s243a]

Without it it maybe OK for building but for the user will be a mess if dpkg/apt is not aware of puppy files and the wild pets scattered all over the forum. If puppy is going to be utilising several distro-specific and native package managers simultaneously, may become a support nightmare.

Agreed. This is a mess. We may want to use packages from many distros, but there should only be ONE package management.

"Pkg" for example can install .debs, .txz, but my impression is (please correct me if I'm wrong) it will convert those foreign packages into its own internal format, and keeps a record of installed packages its own way. This is okay.

But if you try to have both PPM and apt-get active (for example), then all you get is incurable headache.

But I guess is probably a bit early to worry about these

No need to worry. But it's good to plan ahead.

cheers!

It might be difficult to sync the debian package manager because it is pretty finicky (and easy to break), but it would be pretty easy to sync the puppy package manager with tazpkg. The main downside is that you end up with roughly twice the meta-information for your system.

It could be less than twice the meta information because you could symlink/hardlink the list of files for a package.

I suppose another downside is the dependency resolution, since packages might have different names in different repos but there could be some kind of name translation list.

[s243a]

They are OK with you offering “a 5year-dead project” and can not complain when the real issues appear, but if they are offered an active project, all they’ll do is complain as they always did, because they are not really capable to address any issue.

Well, your favourite character has thrown the towel off on that 5year-dead-project

I believe that remotely serious builders have visited github and seen the activity and discussions.

Agreed. There is a certain level of skills involved when you want to build a distro. Ability to use distro =/= ability to build one.

Everyone has to start somewhere and since woof-next has fewer lines of code it is likely an easier place to start to build ones skill. Also troubleshooting issues is what is going to build up someones skill. In a more mature project the issues might be tougher to troubleshoot.

[s243a]

TahrPup is still a very popular puppy. Pointing the repos to the right place is needed rather than deleting it. If it is not generating any troubles for the current puppies (does it?) I would rather see it staying. With the new 'I'll be a puppy builder" enthusiasm who knows what they'll want to build. BTW should people in the forum be notified about the "experimental" branch and its association with the, currently popular, "woof-next" branch or it would be too much noise?

I like tarpup and would be sad to see it go but it is getting dataed. As for how old is too old, JRB is keeping puppies alive as old as precise: http://murga-linux.com/puppy/viewtopic.php?t=115843

and there has also been some afferts -- although perhaps not as recent -- to keep even older versions of puppy alive e.g. Classic Pup: http://murga-linux.com/puppy/viewtopic.php?t=42553&start=5085 Anitaos: https://www.pearltrees.com/s243a/anitaos-puppylinux-4-12-13/id20357145 Lucid: http://murga-linux.com/puppy/viewtopic.php?t=90461

Some people have also been using Wary with a glibc tweak for the palemoon browser but there is no iso available with this tweak.

[jamesbond3142]

It might be difficult to sync the debian package manager because it is pretty finicky (and easy to break), but it would be pretty easy to sync the puppy package manager with tazpkg. The main downside is that you end up with roughly twice the meta-information for your system.

But you still have to sync it and this is a headache. Say, you install a tazpkg. Then both tazpkg record and PPM record must be updated (so both know that a new package have been installed). And if you uninstall a package through PPM, then tazpkg record of that package must be deleted as well.

Everyone has to start somewhere and since woof-next has fewer lines of code it is likely an easier place to start to build ones skill. Also troubleshooting issues is what is going to build up someones skill. In a more mature project the issues might be tougher to troubleshoot.

Agreed.

[s243a]

this is a headache. Say, you install a tazpkg. Then both tazpkg record and PPM record must be updated (so

It might be difficult to sync the debian package manager because it is pretty finicky (and easy to break), but it would be pretty easy to sync the puppy package manager with tazpkg. The main downside is that you end up with roughly twice the meta-information for your system.

But you still have to sync it and this is a headache. Say, you install a tazpkg. Then both tazpkg record and PPM record must be updated (so both know that a new package have been installed). And if you uninstall a package through PPM, then tazpkg record of that package must be deleted as well.

but at the end of the tazpkg command I can call a script that updates the necessary meta data for petget. I can do the same thing at the end of the petget script. I'm not saying that one should do this but I don't think that for these two specific package managers it will be that hard. However, as I note above with the debian package manager this would be much harder to do.

[wdlkmpx]

If you use the compat distro package manager, there's no need to use the ppm. I see there's woof-arch with compiled stuff, then there should be woof-arch-gui as well. It's simple.

That's why i also tend to group rootfs-packages, and merge stuff to rootfs-skeleton. And then i end up detecting failures and deleting broken stuff, making the system smaller and smaller with less puppy stuff.

In fact if you look at it with different eyes, you only need the layered stuff code. I don't mind using the current stuff, i only need up-to-date browser and media player. And the fact that it supports all sorts of cross builds makes it worthwhile despite the many design flaws.

Now talking about tahrpup again, i performed many massive cleanups before. The main problem with the changing architecture is that old assembled pet packages may cause issues, i say this again, the package name must change if fixes are added.

Assessing stuff is time consuming. So i just delete entries and stuff, that's what i've been doing for a loong time..

When i decided to update slacko 14.0, it became completely different, i saw many core scripts in pet packages, i delete a lot of stuff and compiled basically everything again. The kernel stuff is still an issue.

[s243a]

Without it it maybe OK for building but for the user will be a mess if dpkg/apt is not aware of puppy files and the wild pets scattered all over the forum. If puppy is going to be utilising several distro-specific and native package managers simultaneously, may become a support nightmare. Jamesbond wrote: Agreed. This is a mess. We may want to use packages from many distros, but there should only be ONE package management.

"Pkg" for example can install .debs, .txz, but my impression is (please correct me if I'm wrong) it will convert those foreign packages into its own internal format, and keeps a record of installed packages its own way. This is okay.

It probably keeps it's own meta-data but it will call the debian post install scripts:

        if [ -f "${pkg_dir}DEBIAN/postinst" ];then
          mv "${pkg_dir}DEBIAN/postinst" "${PARENTPKG}-${SUFFIX}/DEBIAN/postinst_${count}"
        fi

https://gitlab.com/sc0ttj/Pkg/blob/master/usr/sbin/pkg#L3649

      # run the post install scripts (for puppy, slackware, arch, debian/ubuntu, etc)
      for i in /pinstall.sh /install/doinst.sh /DEBIAN/postinst
      do
        [ -z /${i} -o ! -e /${i} ] && continue
        chmod +x /${i}
        cd /
        nohup sh ${i} &>/dev/null
        sleep 0.2
        rm -f ${i}
        cd ${CURDIR}/
      done

https://gitlab.com/sc0ttj/Pkg/blob/master/usr/sbin/pkg#L4764

However, if one is missing some of the tools that are used in debians package management system then the post install scripts aren't guaranteed to work.